컴퓨팅 서버 UCS C240 M4 - vEPC 교체

다운로드 옵션

PDF (221.7 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (1.0 MB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (644.3 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2021년 7월 19일

문서 ID:213355

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 StarOS VNF(Virtual Network Functions)를 호스팅하는 Ultra-M 설정에서 결함이 있는 컴퓨팅 서버를 교체하는 데 필요한 단계를 설명합니다.

배경 정보

Ultra-M은 VNF 구축을 간소화하기 위해 사전 패키지 및 검증된 가상화 모바일 패킷 코어 솔루션입니다. OpenStack은 Ultra-M용 VIM(Virtualized Infrastructure Manager)이며 다음 노드 유형으로 구성됩니다.

컴퓨팅
개체 스토리지 디스크 - 컴퓨팅(OSD - 컴퓨팅)
컨트롤러
OpenStack Platform - 디렉터(OSPD)

Ultra-M 및 관련 구성 요소의 고급 아키텍처는 다음 이미지에 설명되어 있습니다.

UltraM 아키텍처

이 문서는 Cisco Ultra-M 플랫폼에 익숙한 Cisco 직원을 대상으로 하며, 컴퓨팅 서버 교체 시 OpenStack 및 StarOS VNF 레벨에서 수행해야 하는 단계를 자세히 설명합니다.

참고:Ultra M 5.1.x 릴리스는 이 문서의 절차를 정의하기 위해 고려됩니다.

약어

VNF	가상 네트워크 기능
CF	제어 기능
SF	서비스 기능
ESC	Elastic Service Controller
MOP	절차 방법
OSD	개체 스토리지 디스크
HDD	하드 디스크 드라이브
SSD	솔리드 스테이트 드라이브
VIM	가상 인프라 관리자
VM	가상 머신
EM	요소 관리자
UAS	Ultra Automation 서비스
UUID	보편적으로 고유한 IDentifier

MoP 워크플로

교체 절차의 상위 레벨 워크플로우

사전 요구 사항

백업

컴퓨팅 노드를 교체하기 전에 Red Hat OpenStack Platform 환경의 현재 상태를 확인하는 것이 중요합니다.컴퓨팅 교체 프로세스가 켜져 있을 때 합병증을 피하려면 현재 상태를 확인하는 것이 좋습니다.이러한 교체 흐름으로 달성할 수 있습니다.

복구 시 다음 단계를 사용하여 OSPD 데이터베이스를 백업하는 것이 좋습니다.

[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql
[root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql 
/etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack
tar: Removing leading `/' from member names

이 프로세스에서는 인스턴스 가용성에 영향을 주지 않고 노드를 교체할 수 있습니다. 또한 교체될 컴퓨팅 노드가 CF(Control Function) VM(Virtual Machine)을 호스팅하는 경우 특히 StarOS 구성을 백업하는 것이 좋습니다.

컴퓨팅 노드에서 호스팅되는 VM 식별

컴퓨팅 서버에서 호스팅되는 VM을 식별합니다.두 가지 가능성이 있습니다.

컴퓨팅 서버에는 SF(서비스 함수) VM만 포함되어 있습니다.

[stack@director ~]$ nova list --field name,host | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  
pod1-compute-10.localdomain    |

컴퓨팅 서버에는 VM의 CF(Control Function)/ESC(Elastic Services Controller)/EM(Element Manager)/UAS(Ultra Automation Services) 조합이 포함되어 있습니다.

[stack@director ~]$ nova list --field name,host | grep compute-8
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

참고:여기에 표시된 출력에서 첫 번째 열은 UUID(Universally Unique IDentifier)에 해당하고, 두 번째 열은 VM 이름이고, 세 번째 열은 VM이 있는 호스트 이름입니다.이 출력의 매개변수는 후속 섹션에서 사용됩니다.

정상 전원 끄기

사례 1. 컴퓨팅 노드가 SF VM만 호스팅함

SF 카드를 대기 상태로 마이그레이션

StarOS VNF에 로그인하고 SF VM에 해당하는 카드를 식별합니다."컴퓨팅 노드에서 호스팅되는 VM 식별" 섹션에서 식별된 SF VM의 UUID를 사용하고 UUID에 해당하는 카드를 식별합니다.

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 8:
  Card Type               : 4-Port Service Function Virtual Card
  CPU Packages            : 26 [#0, #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25]
  CPU Nodes               : 2
  CPU Cores/Threads       : 26
  Memory                  : 98304M (qvpc-di-large)
  UUID/Serial Number      :  49AC5F22-469E-4B84-BADC-031083DB0533
<snip>

카드의 상태를 확인합니다.

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Active         No         
 2: CFC      Control Function Virtual Card           Standby        -          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -

카드가 활성 상태인 경우 카드를 대기 상태로 이동합니다.

  [local]VNF2# card migrate from 8 to 10

ESC에서 SF VM 종료

VNF에 해당하는 ESC 노드에 로그인하고 SF VM의 상태를 확인합니다.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

VM 이름을 사용하여 SF VM을 중지합니다.(VM 이름은 "컴퓨팅 노드에서 호스팅되는 VM 식별" 섹션에서 설명):

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

중지되면 VM은 SHUTOFF 상태로 전환되어야 합니다.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip>

Nova Aggregate 목록에서 컴퓨팅 노드 제거

nova 집계를 나열하고 이 집계에서 호스팅되는 VNF를 기반으로 컴퓨팅 서버에 해당하는 집계를 식별합니다.일반적으로 <VNFNAME>-SERVICE<X> 형식입니다.

[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name              | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT   | mgmt              |
| 57 | VNF1-SERVICE1 | -                 |
| 60 | VNF1-EM-MGMT1 | -                 |
| 63 | VNF1-CF-MGMT1 | -                 |
| 66 | VNF2-CF-MGMT2 | -                 |
| 69 | VNF2-EM-MGMT2 | -                 |
| 72 | VNF2-SERVICE2 | -                 |
| 75 | VNF3-CF-MGMT3 | -                 |
| 78 | VNF3-EM-MGMT3 | -                 |
| 81 | VNF3-SERVICE3 | -                 |
+----+-------------------+-------------------+

이 경우 대체할 컴퓨팅 서버는 VNF2에 속합니다. 따라서 해당 집계 목록은 VNF2-SERVICE2가 됩니다.

식별된 집계에서 컴퓨팅 노드를 제거합니다("컴퓨팅 노드에서 호스팅되는 VM 식별" 섹션에서 설명한 호스트 이름으로 제거).

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host VNF2-SERVICE2 pod1-compute-10.localdomain

컴퓨팅 노드가 집계에서 제거되었는지 확인합니다.이제 호스트가 집계 아래에 나열되지 않아야 합니다.

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

사례 2. 컴퓨팅 노드가 CF/ESC/EM/UAS를 호스팅함

CF 카드를 대기 상태로 마이그레이션

StarOS VNF에 로그인하고 CF VM에 해당하는 카드를 식별합니다."컴퓨팅 노드에서 호스팅되는 VM 식별" 섹션에서 식별된 CF VM의 UUID를 사용하고 UUID에 해당하는 카드를 찾습니다.

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 2:
  Card Type               : Control Function Virtual Card
  CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]
  CPU Nodes               : 1
  CPU Cores/Threads       : 8
  Memory                  : 16384M (qvpc-di-large)
  UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2
<snip>

카드의 상태를 확인합니다.

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Standby        -
 2: CFC      Control Function Virtual Card           Active         No          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
 8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -

카드가 활성 상태인 경우 카드를 대기 상태로 이동합니다.

[local]VNF2# card migrate from 2 to 1

ESC에서 CF 및 EM VM 종료

VNF에 해당하는 ESC 노드에 로그인하고 VM의 상태를 확인합니다.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

VM 이름을 사용하여 CF 및 EM VM을 하나씩 중지합니다.(VM 이름은 "컴퓨팅 노드에서 호스팅되는 VM 식별" 섹션에서 설명):

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

VM이 중지되면 SHUTOFF 상태가 됩니다.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    
     
     
       VM_SHUTOFF_STATE 
     
<snip>

ESC를 대기 모드로 마이그레이션

컴퓨팅 노드에 호스팅된 ESC에 로그인하여 마스터 상태에 있는지 확인합니다.대답이 "예"인 경우 ESC를 대기 모드로 전환합니다.

[admin@VNF2-esc-esc-0 esc-cli]$ escadm status
0 ESC status=0 ESC Master Healthy


[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop
Stopping keepalived:                                       [  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status
1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ sudo reboot
Broadcast message from admin@vnf1-esc-esc-0.novalocal
       (/dev/pts/0) at 13:32 ...
The system is going down for reboot NOW!

Nova Aggregate 목록에서 컴퓨팅 노드 제거

nova 집계를 나열하고 이 집계에서 호스팅되는 VNF를 기반으로 컴퓨팅 서버에 해당하는 집계를 식별합니다.일반적으로 <VNFNAME>-EM-MGMT<X> 및 <VNFNAME>-CF-MGMT<X> 형식입니다.

[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name              | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT   | mgmt              |
| 57 | VNF1-SERVICE1 | -                 |
| 60 | VNF1-EM-MGMT1 | -                 |
| 63 | VNF1-CF-MGMT1 | -                 |
| 66 | VNF2-CF-MGMT2 | -                 |
| 69 | VNF2-EM-MGMT2 | -                 |
| 72 | VNF2-SERVICE2 | -                 |
| 75 | VNF3-CF-MGMT3 | -                 |
| 78 | VNF3-EM-MGMT3 | -                 |
| 81 | VNF3-SERVICE3 | -                 |
+----+-------------------+-------------------+

이 경우 컴퓨팅 서버는 VNF2에 속합니다. 따라서 이에 해당하는 집계는 VNF2-CF-MGMT2 및 VNF2-EM-MGMT2입니다.

식별된 집계에서 컴퓨팅 노드를 제거합니다.

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host VNF2-CF-MGMT2 pod1-compute-8.localdomain
[stack@director ~]$ nova aggregate-remove-host VNF2-EM-MGMT2 pod1-compute-8.localdomain

컴퓨팅 노드가 집계에서 제거되었는지 확인합니다.이제 호스트가 집계 아래에 나열되지 않는지 확인합니다.

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show VNF2-CF-MGMT2
[stack@director ~]$ nova aggregate-show  VNF2-EM-MGMT2

컴퓨팅 노드 삭제

이 섹션에 언급된 단계는 컴퓨팅 노드에서 호스팅되는 VM과 상관없이 일반적입니다.

서비스 목록에서 컴퓨팅 노드 삭제

서비스 목록에서 계산 서비스를 삭제합니다.

[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep compute-8
| 404 | nova-compute     | pod1-compute-8.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

openstack compute service delete 
     
     
[stack@director ~]$ openstack compute service delete 404

Neutron 에이전트 삭제

연결된 이전 중성자 에이전트를 삭제하고 컴퓨팅 서버용 vswitch 에이전트를 엽니다.

[stack@director ~]$ openstack network agent list | grep compute-8
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete 
     
     

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03
[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

아이러니한 데이터베이스에서 삭제

아이러니한 데이터베이스에서 노드를 삭제하고 다음을 확인합니다.

[stack@director ~]$ source stackrc

nova show 
     
     
       | grep hypervisor 
     

[stack@director ~]$ nova show pod1-compute-10 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete 
     
     

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a 
[stack@director ~]$ ironic node-list (node delete must not be listed now)

오버클라우드에서 삭제

표시된 내용과 함께 delete_node.sh라는 스크립트 파일을 만듭니다. 언급된 템플릿은 스택 배포에 사용되는 deploy.sh 스크립트와 동일한지 확인합니다.

 delete_node.sh

 openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack

[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod1 49ac5f22-469e-4b84-badc-031083db0533
Deleting the following nodes from stack pod1:
- 49ac5f22-469e-4b84-badc-031083db0533
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s
user   0m0.383s
sys    0m0.086s

OpenStack 스택 작업이 COMPLETE 상태로 이동할 때까지 기다립니다.

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1 | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

새 컴퓨팅 노드 설치

새 UCS C240 M4 서버를 설치하는 단계 및 초기 설정 단계는 다음 위치에서 참조할 수 있습니다.

Cisco UCS C240 M4 서버 설치 및 서비스 가이드

서버를 설치한 후 해당 슬롯에 하드 디스크를 이전 서버로 삽입합니다.

CIMC IP를 사용하여 서버에 로그인합니다.

펌웨어가 이전에 사용한 권장 버전에 따라 다르면 BIOS 업그레이드를 수행합니다.BIOS 업그레이드 단계는 다음과 같습니다.

Cisco UCS C-Series 랙 마운트 서버 BIOS 업그레이드 가이드

물리적 드라이브의 상태를 확인합니다."구성되지 않은 양호"여야 합니다.

스토리지 > Cisco 12G SAS 모듈형 RAID 컨트롤러(SLOT-HBA) > 물리적 드라이브 정보

RAID 레벨 1을 사용하여 물리적 드라이브에서 가상 드라이브를 생성합니다.

스토리지 > Cisco 12G SAS SLOT-HBA(Modular Raid Controller) > 컨트롤러 정보 > 사용되지 않는 물리적 드라이브에서 가상 드라이브 생성

VD를 선택하고 "Set as Boot Drive"를 구성합니다.

IPMI over LAN 사용:

Admin(관리) > Communication Services(통신 서비스) > Communication Services(통신 서비스)

하이퍼스레딩 사용 안 함:

컴퓨팅 > BIOS > BIOS 구성 > 고급 > 프로세서 구성

참고:여기에 표시된 이미지와 이 섹션에 언급된 컨피그레이션 단계는 펌웨어 버전 3.0(3e)에 대한 참조이며, 다른 버전에서 작업하는 경우 약간의 차이가 있을 수 있습니다.

오버클라우드에 새 컴퓨팅 노드 추가

이 섹션에 언급된 단계는 컴퓨팅 노드에서 호스팅되는 VM과 상관없이 일반적입니다.

다른 인덱스로 컴퓨팅 서버 추가

추가할 새 컴퓨팅 서버의 세부 정보만 사용하여 add_node.json 파일을 생성합니다.새 컴퓨팅 서버의 인덱스 번호가 이전에 사용되지 않았는지 확인합니다.일반적으로 다음으로 높은 컴퓨팅 값을 증가시킵니다.

예:가장 높은 우선순위는 컴퓨팅-17이므로 2-vnf 시스템의 경우 컴퓨팅-18을 생성했습니다.

참고:json 형식에 유의하십시오.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "<MAC_ADDRESS>"
            ],
            "capabilities": "node:compute-18,boot_option:local",
            "cpu":"24",
            "memory":"256000",
            "disk":"3000",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"<PASSWORD>",
            "pm_addr":"192.100.0.5"
        }
    ]
}

json 파일을 가져옵니다.

[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.

이전 단계에서 설명한 UUID를 사용하여 노드 자체 검사를 실행합니다.

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

새 컴퓨팅 노드를 오버클라우드 스택에 추가하기 위해 이전에 스택을 구축하는 데 사용한 deploy.sh 스크립트를 실행합니다.

[stack@director ~]$ ./deploy.sh
++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
…
Starting new HTTP connection (1): 192.200.0.1
"POST /v2/action_executions HTTP/1.1" 201 1695
HTTP POST http://192.200.0.1:8989/v2/action_executions 201
Overcloud Endpoint: http://10.1.2.5:5000/v2.0
Overcloud Deployed
clean_up DeployOvercloud: 
END return value: 0

real   38m38.971s
user   0m3.605s
sys    0m0.466s

openstack 스택 상태가 Complete(완료)가 될 때까지 기다립니다.

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

새 컴퓨팅 노드가 활성 상태인지 확인합니다.

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep compute-18
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-compute-18    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep compute-18
| 63 | pod1-compute-18.localdomain    |

사후 서버 교체 설정

오버클라우드에 서버를 추가한 후 이전 서버에 이전에 있었던 설정을 적용하려면 아래 링크를 참조하십시오.

VM 복원

사례 1. 컴퓨팅 노드가 SF VM만 호스팅함

Nova Aggregate 목록 추가

종합 호스트에 컴퓨팅 노드를 추가하고 호스트가 추가되었는지 확인합니다.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host VNF2-SERVICE2 pod1-compute-18.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

ESC에서 SF VM 복구

SF VM은 nova 목록에서 오류 상태가 됩니다.

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     |

ESC에서 SF VM을 복구합니다.

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

양세초에서 다음을 모니터링합니다.

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

SF 카드가 VNF에서 대기 SF로 나타나는지 확인합니다.

사례 2. 컴퓨팅 노드가 CF, ESC, EM 및 UAS를 호스팅함

Nova Aggregate 목록 추가

종합 호스트에 컴퓨팅 노드를 추가하고 호스트가 추가되었는지 확인합니다.이 경우 CF 및 EM 호스트 집계에 컴퓨팅 노드를 추가해야 합니다.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host VNF2-CF-MGMT2 pod1-compute-18.localdomain
[stack@director ~]$ nova aggregate-add-host VNF2-EM-MGMT2 pod1-compute-18.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show VNF2-CF-MGMT2
[stack@director ~]$ nova aggregate-show VNF2-EM-MGMT2

UAS VM 복구

nova 목록에서 UAS VM의 상태를 확인하고 삭제합니다.

[stack@director ~]$ nova list | grep VNF2-UAS-uas-0
| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | VNF2-UAS-uas-0                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.10; VNF2-UAS-uas-management=172.168.10.3
[stack@tb5-ospd ~]$ nova delete VNF2-UAS-uas-0
Request to delete server VNF2-UAS-uas-0 has been accepted.

autovnf-uas VM을 복구하려면 uas-check 스크립트를 실행하여 상태를 확인합니다.오류를 보고해야 합니다.그런 다음 —fix 옵션을 사용하여 다시 실행하여 누락된 UAS VM을 다시 생성합니다.

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts/
[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS
2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors

[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS --fix
2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
2017-11-22 14:01:09,575 - INFO: Instance VNF2-UAS-uas-0' status is 'ERROR'
2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-22 14:01:09,778 - INFO: Removing instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Removed instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Creating instance VNF2-UAS-uas-0' and attaching volume ‘VNF2-UAS-uas-vol-0'
2017-11-22 14:01:49,525 - INFO: Created instance ‘VNF2-UAS-uas-0'

autovnf-uas에 로그인합니다.몇 분 정도 기다리면 UAS가 정상 상태로 돌아와야 합니다.

VNF2-autovnf-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.17.181.101
INSTANCE IP   STATE  ROLE
-----------------------------------
172.17.180.6  alive  CONFD-SLAVE
172.17.180.7  alive  CONFD-MASTER
172.17.180.9  alive  NA

참고:uas-check.py —fix가 실패하면 이 파일을 복사하고 다시 실행해야 할 수 있습니다.

[stack@director ~]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/
[stack@director ~]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/

ESC VM 복구

nova 목록에서 ESC VM의 상태를 확인하고 삭제합니다.

stack@director scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | VNF2-ESC-ESC-1                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
[stack@director scripts]$ nova delete VNF2-ESC-ESC-1
Request to delete server VNF2-ESC-ESC-1 has been accepted.

AutoVNF-UAS에서 ESC 구축 트랜잭션을 찾은 다음 트랜잭션 로그에서 ESC 인스턴스를 만들기 위한 boot_vm.py 명령줄을 찾습니다.

ubuntu@VNF2-uas-uas-0:~$ sudo -i
root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI    
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show transaction
TX ID                                 TX TYPE          DEPLOYMENT ID    TIMESTAMP                         STATUS
-----------------------------------------------------------------------------------------------------------------------------
35eefc4a-d4a9-11e7-bb72-fa163ef8df2b  vnf-deployment   VNF2-DEPLOYMENT  2017-11-29T02:01:27.750692-00:00  deployment-success
73d9c540-d4a8-11e7-bb72-fa163ef8df2b  vnfm-deployment  VNF2-ESC         2017-11-29T01:56:02.133663-00:00  deployment-success


VNF2-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
  <logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
    <tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
    <log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: VNF2-ESC, deactivate: 0
2017-11-29 01:56:02,179 - Notify deployment
..
2017-11-29 01:57:30,385 - Creating VNFM 'VNF2-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

boot_vm.py 줄을 셸 스크립트 파일(esc.sh)에 저장하고 모든 사용자 이름 ***** 및 암호 ****** 줄을 올바른 정보로 업데이트합니다(일반적으로 core/<PASSWORD>). -encrypt_key 옵션도 제거해야 합니다.user_pass 및 user_confd_pass의 경우 username 형식을 사용해야 합니다.password(예: admin:<PASSWORD>).

running-config에서 bootvm.py에 대한 URL을 찾아 bootvm.py 파일을 autovnf-uas VM에 가져옵니다. 이 경우 10.1.2.3은 Auto-IT VM의 IP입니다.

root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show running-config autovnf-vnfm:vnfm
…
configs bootvm
  value http:// 10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
!

root@VNF2-uas-uas-0:~# wget http://10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
--2017-12-01 20:25:52--  http://10.1.2.3 /bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
Connecting to 10.1.2.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127771 (125K) [text/x-python]
Saving to: ‘bootvm-2_3_2_155.py’
100%[=====================================================================================>] 127,771  --.-K/s   in 0.001s
2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771]

다음과 같이 /tmp/esc_params.cfg 파일을 생성합니다.

root@VNF2-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg

셸 스크립트를 실행하여 UAS 노드에서 ESC를 구축합니다.

root@VNF2-uas-uas-0:~# /bin/sh esc.sh
+ python ./bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689
 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url 
http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username core --os_password <PASSWORD> --bs_os_auth_url 
http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password <PASSWORD> 
--esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:<PASSWORD> --user_confd_pass 
admin:<PASSWORD> --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3
172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh 
--file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py 
--file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

새 ESC에 로그인하고 백업 상태를 확인합니다.

ubuntu@VNF2-uas-uas-0:~$ ssh admin@172.168.11.14
…
   ####################################################################
   #   ESC on VNF2-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

[admin@VNF2-esc-esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) ===================================================
ESC HEALTH PASSED

ESC에서 CF 및 EM VM 복구

nova 목록에서 CF 및 EM VM의 상태를 확인합니다.ERROR 상태여야 합니다.

[stack@director ~]$ source corerc
[stack@director ~]$ nova list --field name,host,status |grep -i err   
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | None                                 | ERROR|
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     |None                                 | ERROR

ESC 마스터에 로그인하고 영향을 받는 각 EM 및 CF VM에 대해 recovery-vm-action을 실행합니다.인내심을 가지세요.ESC는 복구 작업을 예약하며 몇 분 동안 이 작업이 수행되지 않을 수 있습니다.양세초에서 다음을 모니터링합니다.

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO 
     
     

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

[admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8]

새 EM에 로그인하여 EM 상태가 작동 중인지 확인합니다.

ubuntu@VNF2vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
admin connected from 172.17.180.6 using ssh on VNF2vnfddeploymentem-1
admin@scm# show ems
EM            VNFM
ID  SLA  SCM  PROXY
---------------------
2   up   up   up
3   up   up   up

StarOS VNF에 로그인하여 CF 카드가 대기 상태인지 확인합니다.

ESC 복구 실패 처리

예기치 않은 상태로 인해 ESC가 VM을 시작하지 못하는 경우 Cisco에서는 마스터 ESC를 재부팅하여 ESC 전환을 수행하는 것이 좋습니다.ESC 전환에는 약 1분이 소요됩니다.새 마스터 ESC에서 "health.sh" 스크립트를 실행하여 상태가 작동 중인지 확인합니다.VM을 시작하고 VM 상태를 수정하려면 마스터 ESC를 누릅니다.이 복구 작업을 완료하는 데 최대 5분이 소요됩니다.

/var/log/esc/yangesc.log 및 /var/log/esc/escmanager.log을 모니터링할 수 있습니다.5~7분 후 VM이 복구되지 않는 경우, 사용자는 이동하여 영향을 받는 VM을 수동으로 복구해야 합니다.

구성 업데이트 자동 배포

AutoDeploy VM에서 autodeploy.cfg를 편집하고 기존 컴퓨팅 서버를 새 컴퓨팅 서버로 대체합니다. 그런 다음 confd_cli에서 replace를 로드합니다. 이 단계는 나중에 성공적으로 구축 비활성화에 필요합니다.

root@auto-deploy-iso-2007-uas-0:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0
auto-deploy-iso-2007-uas-0#config
Entering configuration mode terminal
auto-deploy-iso-2007-uas-0(config)#load replace autodeploy.cfg
Loading.     14.63 KiB parsed in 0.42 sec (34.16 KiB/sec)

auto-deploy-iso-2007-uas-0(config)#commit
Commit complete.
auto-deploy-iso-2007-uas-0(config)#end

구성 변경 후 uas-confd 및 autodeploy 서비스를 다시 시작합니다.

root@auto-deploy-iso-2007-uas-0:~# service uas-confd restart
uas-confd stop/waiting
uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service uas-confd status
uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service autodeploy restart
autodeploy stop/waiting
autodeploy start/running, process 14017
root@auto-deploy-iso-2007-uas-0:~# service autodeploy status
autodeploy start/running, process 14017

Syslogs 활성화

UCS 서버, Openstack 구성 요소 및 복구된 VM에 대한 syslog를 활성화하려면 다음 절을 따르십시오.

아래 링크에서 "UCS 및 Openstack 구성 요소에 대한 syslog 다시 활성화" 및 "VNF에 대한 syslog 사용":

컴퓨팅 서버 UCS C240 M4 - vEPC 교체

다운로드 옵션

편견 없는 언어

이 번역에 관하여

목차

소개

배경 정보

약어

MoP 워크플로

사전 요구 사항

백업

컴퓨팅 노드에서 호스팅되는 VM 식별

정상 전원 끄기

사례 1. 컴퓨팅 노드가 SF VM만 호스팅함

SF 카드를 대기 상태로 마이그레이션

ESC에서 SF VM 종료

Nova Aggregate 목록에서 컴퓨팅 노드 제거

사례 2. 컴퓨팅 노드가 CF/ESC/EM/UAS를 호스팅함

CF 카드를 대기 상태로 마이그레이션

ESC에서 CF 및 EM VM 종료

ESC를 대기 모드로 마이그레이션

Nova Aggregate 목록에서 컴퓨팅 노드 제거

컴퓨팅 노드 삭제

서비스 목록에서 컴퓨팅 노드 삭제

Neutron 에이전트 삭제

아이러니한 데이터베이스에서 삭제

오버클라우드에서 삭제

새 컴퓨팅 노드 설치

오버클라우드에 새 컴퓨팅 노드 추가

사후 서버 교체 설정

VM 복원

사례 1. 컴퓨팅 노드가 SF VM만 호스팅함

Nova Aggregate 목록 추가

ESC에서 SF VM 복구

사례 2. 컴퓨팅 노드가 CF, ESC, EM 및 UAS를 호스팅함

Nova Aggregate 목록 추가

UAS VM 복구

ESC VM 복구

ESC 복구 실패 처리

구성 업데이트 자동 배포

Syslogs 활성화

관련 정보

개정 이력

Cisco 엔지니어가 작성

이 문서가 도움이 되셨습니까?

지원 문의

이 문서가 적용되는 제품