サーバ UCS C240 M4 の欠陥のあるコンポーネントの置換- vEPC

ダウンロード オプション

  • PDF     (438.5 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (207.1 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (183.3 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2018 年 7 月 2 日
Document ID:213464

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    概要

    ホスト StarOS バーチャルネットワークが機能することこの資料が設定される Ultra-M の Unified Computing System （UCS）サーバでここに述べられる欠陥のあるコンポーネントを交換するために必要なステップを記述したものです（VNFs）。 

    • Dual In-Line Memory Module （DIMM）置換 MOP
    • FlexFlash コントローラ障害
    • ソリッド ステート ドライブ（SSD）失敗 
    • 信頼されたプラットフォーム モジュール（TPM）失敗
    • 侵略キャッシュ失敗
    • 侵略コントローラ熱いバス アダプタ（HBA）失敗
    • PCI 暴徒失敗
    • PCIe アダプタ Intel X520 10G 失敗
    • マザーボード（MLOM）失敗 LAN でモジュラ
    • ファン トレイ RMA
    • CPU 失敗

    背景説明

    Ultra-M は事前包装され、検証された仮想化されたモービル パケット コア ソリューションです VNFs の配備を簡素化するために設計されている。 OpenStack は Ultra-M のための Virtualized Infrastructure Manager （VIM）で、これらのノードタイプで構成されています:

    • 計算
    • オブジェクト ストレージ ディスク-計算（OSD -計算）
    • コントローラ
    • OpenStack プラットフォーム-ディレクター（OSPD）

    Ultra-M の高レベル アーキテクチャおよび含まれるコンポーネントはこのイメージで描写されます:

    この資料は Cisco Ultra-M プラットフォームについて詳しく知っているサーバのコンポーネント置換の時に OpenStack および StarOS VNF レベルで遂行されることを必要なステップを詳述します Cisco社員のために意図され。 

    注: 超 M 5.1.x リリースはこの資料の手順を定義するために考慮されます。

    省略形

    VNF   バーチャルネットワーク 機能
    CF    制御機能
    SF    サービス 機能
    ESC   伸縮性があるサービス コントローラ
    MOP   プロシージャの方式
    OSD   オブジェクト ストレージ ディスク
    HDD   ハードディスク ドライブ
    SSD   ソリッド ステート ドライブ
    VIM   仮想 な インフラストラクチャ マネージャ
    VM    仮想マシン
    EM    Element Manager
    UAS   Ultra Automation Services
    UUID   ユニバーサル固有の識別番号

    Mop の作業の流れ 

    213464-replacement-of-faulty-components-on-serv-00.png

    前提条件

    バックアップ

    欠陥のあるコンポーネントを交換する前に、Red Hat OpenStack プラットフォーム 環境の現在のステートをチェックすることは重要です。 交換の手順がオンになっているとき複雑な状況を避けるためにチェック 現在のステート推奨します。 それを置換のこのフローによって達成することができます。

    リカバリの場合には、Cisco はこれらのステップの使用の 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


    このプロセスはノードが例ことをのアベイラビリティに影響を与えないで取り替えることができるようにします。 また特に取り替えられるべき compute/OSD 計算ノードが制御機能（CF） Virtual Machine （VM）をホストすれば、StarOS 設定をバックアップすることを推奨します。

    注: サーバが Controller ノードである場合、セクション""に進んで下さい、次の セクションと他では続けて下さい。


    コンポーネント RMA - Compute/OSD 計算ノード 

    Compute/OSD 計算ノードでホストされる VM を識別して下さい

    サーバでホストされる VM を識別して下さい。 2 つの可能性がある場合もあります:

    • サーバはサービス 機能だけ（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    |

      

    • サーバ含んでいます制御機能（CF） /Elastic サービス コントローラ（）/Element Manager （EM）超 ESC/VM のオートメーション サービス（UAS）組み合せ:

    [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）に、2番目のカラムです VM 名前ユニバーサル対応し、第 3 カラムは VM があるホスト名です。 この出力からのパラメータはそれに続くセクションで使用されます。

    電源遮断の段階的

    1.計算ノード ホスト SF だけ VM を包装して下さい

    STANDBY 状態に SF カードを移行して下さい

    • SF VM に対応する StarOS VNF へのログインはカードを識別し。 セクションから「識別される SF VM の UUID を識別し UUID に対応する Compute/OSD 計算ノードで」ホストされる VM を識別しますカードを使用して下さい:
    [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
    • カードのステータスをチェックして下さい:
    [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        -  
    • カードが ACTIVE 状態にある場合、STANDBY 状態にカードを移動して下さい:
      [local]VNF2# card migrate from 8 to 10

    ESC からの SF VM をシャットダウンして下さい

    • VNF に対応する SF VM のステータスをチェックし、ESC ノードへのログインは:

    [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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                        VM_ALIVE_STATE
                         VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
                        VM_ALIVE_STATE</state>
    <snip>
    • VM 名前の使用の SF VM を停止して下さい。 （セクションからの VM ネーム注目される「Compute/OSD 計算ノードで」ホストされる VM を識別します）:

    [admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
    •  それが停止すれば、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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                        VM_ALIVE_STATE
                        VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                        VM_ALIVE_STATE
                        VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
                        VM_SHUTOFF_STATE</state>

    ケース 2. Compute/OSD 計算ノード ホスト CF/ESC/EM/UAS

    STANDBY 状態への移行する CF カード

    • CF VM に対応する StarOS VNF へのログインはカードを識別し。 セクションから「識別される CF VM の UUID を識別し UUID に対応するノードで」ホストされる VM を見つけますカードを使用して下さい:

    [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        -
    • カードが ACTIVE 状態にある場合、STANDBY 状態にカードを移動して下さい:

    [local]VNF2# card migrate from 2 to 1

    ESC からの CF および EM VM をシャットダウンして下さい

    • VNF に対応する VM のステータスをチェックし、ESC ノードへのログインは:

    [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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                        VM_ALIVE_STATE</state>
                        VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                        VM_ALIVE_STATE
    <deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                      507d67c2-1d00-4321-b9d1-da879af524f8
                      dc168a6a-4aeb-4e81-abd9-91d7568b5f7c
                      9ffec58b-4b9d-4072-b944-5413bf7fcf07
                    SERVICE_ACTIVE_STATE
                        VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea
                        VM_ALIVE_STATE</state>
    <snip>
    • VM 名前の使用と CF および EM VM を順次に停止して下さい。 （セクションからの VM ネーム注目される「Compute/OSD 計算ノードで」ホストされる 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 は切断状態を入力する必要があります:

    [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>
                        VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                        VM_SHUTOFF_STATE</state>
                        VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                        VM_ALIVE_STATE
    <deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                      507d67c2-1d00-4321-b9d1-da879af524f8
                      dc168a6a-4aeb-4e81-abd9-91d7568b5f7c
                      9ffec58b-4b9d-4072-b944-5413bf7fcf07
                    SERVICE_ACTIVE_STATE
                        VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                        <state>VM_SHUTOFF_STATE</state>
    <snip>

    スタンバイ モードへの移行する ESC

    • マスター状態にある場合ノードおよびチェックでホストされる ESC へのログイン。 Yes の場合は、スタンバイ モードに 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!

    注: 欠陥のあるコンポーネントが OSD 計算ノードで取り替えられるべきならコンポーネント置換を続行する前にサーバでメンテナンスに Ceph を入れて下さい。 

    [admin@osd-compute-0 ~]$ sudo ceph osd set norebalance
    set norebalance

    [admin@osd-compute-0 ~]$ sudo ceph osd set noout
    set noout

    [admin@osd-compute-0 ~]$ sudo ceph status
        cluster eb2bb192-b1c9-11e6-9205-525400330666
         health HEALTH_WARN
                noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
         monmap e1: 3 mons at {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}
                election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-pod1-controller-2
         osdmap e194: 12 osds: 12 up, 12 in
                flags noout,norebalance,sortbitwise,require_jewel_osds
          pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects
                1585 GB used, 11808 GB / 13393 GB avail
                     704 active+clean
      client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

    Compute/OSD 計算ノードからの欠陥のあるコンポーネントを交換して下さい

    電源遮断の指定されたサーバー。 ステップは UCS C240 M4 サーバの欠陥のあるコンポーネントを交換するためにから参照することができます: 

    サーバコンポーネントの交換

    VM を復元する

     1.計算ノード ホスト SF だけ VM を包装して下さい

     ESC からの SF VM リカバリ

    • SF VM は新星リストのエラー状態にあります:

    [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>
    • yangesc.log を監視して下さい:

    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. Compute/OSD 計算ノード ホスト CF、ESC、EM および UAS を包装して下さい

      UAS VM のリカバリ

    • 新星リストの 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 チェック スクリプト チェック状態を実行して下さい。 それはエラーを報告する必要があります。 それからと再度実行して下さい ----抜けた 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 なら ----修正は失敗します、このファイルをコピーし、再度動作する必要があるかもしれません。

    [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 のリカバリ

    • 新星リストからの 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 から、boot_vm.py コマンド・ラインを ESC 例を作成するために見つけるとトランザクションのためのログの ESC 配備トランザクションが見つければ:

    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 に関しては、–ユーザ名 形式を使用する必要があります: パスワード（例- admin: <PASSWORD>）。

    • autovnf-uas VM に running-config および wget からの URL bootvm.py を bootvm.pyfile 見つけて下さい。  この場合、10.1.2.3 は自動 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 を回復 して下さい

    • 新星リストからの CF および EM VM のステータスをチェックして下さい。 それらはエラー状態にある必要があります:

    [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 のためのリカバリ vm 処理を実行します。 忍耐強くであって下さい。 ESC はリカバリ処理をスケジュールし、数分間起こらないかもしれません。 yangesc.log を監視して下さい:
    sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO <VM-Name>

    [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 カードが STANDBY 状態にあることを確認して下さい

       

    ESC リカバリ失敗を処理して下さい

    ESC が予想外状態による VM を開始しなければマスター ESC のリブートによって ESC スイッチオーバを行う方法を Cisco は推奨します。 ESC スイッチオーバは約少しだけ時間がかかります。 ステータスが稼働しているかどうか確認するために新しいマスター ESC のスクリプト「health.sh」を実行して下さい。 VM を開始し、VM 状態を修復するために ESC をマスターして下さい。 このリカバリ タスクは 5 分程完了するためにかかります。

    /var/log/esc/yangesc.log および /var/log/esc/escmanager.log を監視できます。 5-7 分後に回復 された VM gets はユーザ影響を与えられた VM の手動リカバリをすることを行く必要があることがわからなければ。

    自動導入 設定アップデート

    • AutoDeploy VM から、autodeploy.cfg を編集し、新しいものと古い計算サーバを取り替えて下さい。 それからロードは confd_cli で取り替えます。 正常な配置非アクティブ化以降にこのステップが必要となります:
    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

    コンポーネント RMA - Controller ノード

    事前点検

                                                       

    • OSPD から、コントローラへのログオンはパソコンがよい州に 3 コントローラ オンラインすべてであり、ガレラ川がマスターとしてすべての 3 人のコントローラを示すことを確認し。 

    注: 健全なクラスタは 2 つのアクティブ コントローラを必要とします従って残る 2 人のコントローラがオンラインおよびアクティブであることを確認して下さい。

    [heat-admin@pod1-controller-0 ~]$ sudo pcs status
    Cluster name: tripleo_cluster
    Stack: corosync
    Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
    Last updated: Mon Dec  4 00:46:10 2017                        Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0
    3 nodes and 22 resources configured

    Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

    Full list of resources:
     ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     ip-11.120.0.49  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     Clone Set: haproxy-clone [haproxy]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Master/Slave Set: galera-master [galera]
         Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     Clone Set: rabbitmq-clone [rabbitmq]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Master/Slave Set: redis-master [redis]
         Masters: [ pod1-controller-2 ]
         Slaves: [ pod1-controller-0 pod1-controller-1 ]
     ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2
     my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-0
     my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-0
     my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-0

    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

    メンテナンス モードにコントローラ クラスタを移動して下さい

    • スタンバイでアップデートされるコントローラのパソコン クラスタを使用して下さい:
    [heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
    • パソコン ステータスを再度チェックし、パソコンがこのノードで停止されてクラスタ化するようにして下さい:
    [heat-admin@pod1-controller-0 ~]$ sudo pcs status
    Cluster name: tripleo_cluster
    Stack: corosync
    Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
    Last updated: Mon Dec  4 00:48:24 2017                        Last change: Mon Dec  4 00:48:18 2017 by root via crm_attribute on pod1-controller-0
    3 nodes and 22 resources configured

    Node pod1-controller-0: standby

    Online: [ pod1-controller-1 pod1-controller-2 ]

    Full list of resources:
     ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     ip-11.120.0.49  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     Clone Set: haproxy-clone [haproxy]
         Started: [ pod1-controller-1 pod1-controller-2 ]
         Stopped: [ pod1-controller-0 ]
    Master/Slave Set: galera-master [galera]
         Masters: [ pod1-controller-1 pod1-controller-2 ]
         Slaves: [ pod1-controller-0 ]
     ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     Clone Set: rabbitmq-clone [rabbitmq]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Master/Slave Set: redis-master [redis]
         Masters: [ pod1-controller-2 ]
         Slaves: [ pod1-controller-1 ]
         Stopped: [ pod1-controller-0 ]
     ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2
     my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1
     my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1
     my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled               

    また、他の 2 人のコントローラのパソコン ステータスはスタンバイとしてノードを示す必要があります。

    Controller ノードからの欠陥のあるコンポーネントを交換して下さい

    電源遮断の指定されたサーバー。 ステップは UCS C240 M4 サーバの欠陥のあるコンポーネントを交換するためにから参照することができます: 

    サーバコンポーネントの交換

    サーバの電源

    • サーバの電源はサーバがアップすることを確認し、:
    [stack@tb5-ospd ~]$ source stackrc
    [stack@tb5-ospd ~]$ nova list |grep pod1-controller-0
    | 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.112 |
    • 影響を与えられたコントローラにログインして下さい、unstandby の使用とスタンバイ モードを取除いて下さい。 コントローラがオンライン クラスタの来、ガレラ川がマスターとしてすべての 3 人のコントローラを示すことを確認して下さい。 これは数分かかるかもしれません:
    [heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby

    [heat-admin@pod1-controller-0 ~]$ sudo pcs status
    Cluster name: tripleo_cluster
    Stack: corosync
    Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
    Last updated: Mon Dec  4 01:08:10 2017                        Last change: Mon Dec  4 01:04:21 2017 by root via crm_attribute on pod1-controller-0
    3 nodes and 22 resources configured

    Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

    Full list of resources:
     ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     ip-11.120.0.49  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     ip-192.200.0.102          (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     Clone Set: haproxy-clone [haproxy]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
    Master/Slave Set: galera-master [galera]
         Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
     Clone Set: rabbitmq-clone [rabbitmq]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Master/Slave Set: redis-master [redis]
         Masters: [ pod1-controller-2 ]
         Slaves: [ pod1-controller-0 pod1-controller-1 ]
     ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
     openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2
     my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1
     my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1
     my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

    • 健全な状態にあることいくつかの ceph のようなモニタ サービスをチェックできます:
    [heat-admin@pod1-controller-0 ~]$ sudo ceph -s
        cluster eb2bb192-b1c9-11e6-9205-525400330666
         health HEALTH_OK
         monmap e1: 3 mons at {pod1-controller-0=11.118.0.10:6789/0,pod1-controller-1=11.118.0.11:6789/0,pod1-controller-2=11.118.0.12:6789/0}
                election epoch 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
         osdmap e218: 12 osds: 12 up, 12 in
                flags sortbitwise,require_jewel_osds
          pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects
                2142 GB used, 11251 GB / 13393 GB avail
                     704 active+clean
      client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr
    TAC Authored

    シスコ エンジニア提供

    • Prashanth Shetty
      Cisco アドバンスド サービス
    • Padmaraj Ramanoudjam
      Cisco アドバンスド サービス

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ

    このドキュメントは次の製品に対応しています