OSD-Compute UCS 240M4の交換 – CPAR
内容
概要
このドキュメントでは、Ultra-Mセットアップで故障したオブジェクトストレージディスク(OSD)コンピューティングサーバを交換するために必要な手順について説明します。
この手順は、ESCがCPARを管理せず、CPARがOpenstackに導入された仮想マシン(VM)に直接インストールされるNEWTONバージョンのOpenstack環境に適用されます。
背景説明
Ultra-Mは、VNFの導入を簡素化するために設計された、パッケージ化および検証済みの仮想化モバイルパケットコアソリューションです。OpenStackは、Ultra-MのVirtual Infrastructure Manager(VIM)であり、次のノードタイプで構成されます。
- 計算
- OSD – コンピューティング
- コントローラ
- OpenStackプラットフォーム – Director(OSPD)
Ultra-Mのアーキテクチャと関連するコンポーネントを次の図に示します。
このドキュメントは、Cisco Ultra-Mプラットフォームに精通しているシスコの担当者を対象としており、OpenStackおよびRedhat Operating System(OS)で実行する必要がある手順の詳細を説明しています。
省略形
| MOP | メソッド |
| OSD | オブジェクトストレージディスク |
| OSPD | OpenStack Platform Director |
| HDD | ハードディスクドライブ |
| SSD | ソリッドステートドライブ |
| VIM | 仮想インフラストラクチャマネージャ |
| VM | 仮想マシン |
| EM | エレメント マネージャ |
| UAS | Ultra Automation Services |
| UUID | ユニバーサル一意IDentifier |
MoPのワークフロー
バックアップ
コンピュートノードを置き換える前に、Red Hat OpenStackプラットフォーム環境の現在の状態を確認することが重要です。コンピューティングの交換プロセスがオンの場合は、複雑さを避けるために現在の状態を確認することをお勧めします。この交換フローによって実現できます。
リカバリの場合は、次の手順を使用して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
このプロセスにより、インスタンスの可用性に影響を与えることなく、ノードを確実に交換できます。
- OSDコンピューティングノードでホストされるVMを特定します。
- サーバでホストされているVMを特定します。
[stack@director ~]$ nova list --field name,host | grep osd-compute-0 | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |
CPARアプリケーションのシャットダウン
ステップ1：ネットワークに接続されているSecure Shell(SSH)クライアントを開き、CPARインスタンスに接続します。
1つのサイト内のすべての4つのAAAインスタンスを同時にシャットダウンしないようにし、1つずつ実行することが重要です。
ステップ2:CPARアプリケーションをシャットダウンするには、次のコマンドを実行します。
/opt/CSCOar/bin/arserver stop
「Cisco Prime Access Registrar Server Agent shutdown complete」というメッセージ 表示する必要があります。
ERROR: You cannot shut down Cisco Prime Access Registrar while the
CLI is being used. Current list of running
CLI with process id is:
2903 /opt/CSCOar/bin/aregcmd –s
この例では、CPARを停止する前に、強調表示されたプロセスID 2903を終了する必要があります。このような場合は、次のコマンドを実行して、このプロセスを終了します。
kill -9 *process_id*
次に、ステップ1を繰り返します。
ステップ3:CPARアプリケーションが実際にシャットダウンされたことを確認するには、次のコマンドを実行します。
/opt/CSCOar/bin/arstatus
次のメッセージが表示されます。
Cisco Prime Access Registrar Server Agent not running Cisco Prime Access Registrar GUI not running
VMスナップショットタスク
ステップ1：現在作業中のサイト（都市）に対応するHorizon GUI Webサイトを入力します。
Horizonにアクセスすると、次の図に示すように画面が表示されます。
ステップ2：次の図に示すように、[プロジェクト] > [インスタンス]に移動します。
ユーザがCPARの場合、このメニューには4つのAAAインスタンスだけが表示されます。
ステップ3：一度に1つのインスタンスだけをシャットダウンし、このドキュメントのプロセス全体を繰り返します。VMをシャットダウンするには、図に示すように[Actions] > [Shut Off Instance]に移動し、選択内容を確認します。
ステップ4：次の図に示すように、ステータス=シャットオフおよび電源の状態=シャットダウンをチェックして、インスタンスが実際にシャットダウンされたことを確認します。
この手順により、CPARシャットダウンプロセスが終了します。
VMスナップショット
CPAR VMがダウンすると、スナップショットは独立した計算に属するため、並行して取得できます。
4つのQCOW2ファイルが並行して作成されます。
各AAAインスタンスのスナップショットを作成します。（25分–1時間）（qcowイメージをソースとして使用したインスタンスは25分、rawイメージをソースとして使用したインスタンスは1時間）
- PODのOpenstackのHorizon GUIにログインします。
- ログインしたら、トップメニューの[Project] > [Compute] > [Instances]セクションに移動し、次の図に示すようにAAAインスタンスを探します。
3.次の図に示すように、[Create Snapshot]をクリックして、スナップショットの作成を続行します（これは、対応するAAAインスタンスで実行する必要があります）。
4.スナップショットが実行されたら、[Images]をクリックして、すべての完了を確認し、次の図に示すように問題が報告されていないことを確認します。
5.次のステップは、このプロセス中にOSPDが失われた場合に、QCOW2形式でスナップショットをダウンロードし、リモートエンティティに転送することです。これを行うには、コマンドglance image-listをOSPDレベルで実行して、スナップショットを識別してください。
[root@elospd01 stack]# glance image-list +--------------------------------------+---------------------------+ | ID | Name | +--------------------------------------+---------------------------+ | 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary | | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017 | | 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017 | | e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image | | 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017 | | 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso | | 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 | +--------------------------------------+---------------------------+
6.ダウンロードするスナップショット（緑色でマークされているスナップショット）を特定したら、コマンドglance image-downloadを使用してQCOW2形式でダウンロードできます。
[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &
- プロセスをバックランドに送信する(&S)この操作を完了するには時間がかかります。完了すると、イメージは/tmpディレクトリに配置されます。
- プロセスをバックグラウンドに送信すると、接続が失われると、プロセスも停止します。
- disown -hコマンドを実行して、SSH接続が失われた場合でも、プロセスがOSPDで実行されて終了するようにします。
7.ダウンロードプロセスが終了したら、圧縮プロセスを実行する必要があります。これは、OSによって処理されるプロセス、タスク、一時ファイルが原因で、スナップショットがゼロで埋められるためです。ファイル圧縮に使用するコマンドはvirt-sparsifyです。
[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2
このプロセスには時間がかかる場合があります（約10 ～ 15分）。 完了すると、次の手順で指定した外部エンティティに転送する必要があるファイルが生成されます。
ファイルの整合性を確認する必要があります。これを行うには、次のコマンドを実行し、出力の最後に「corrupt」属性を探します。
[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2 image: AAA-CPAR-LGNoct192017_compressed.qcow2 file format: qcow2 virtual size: 150G (161061273600 bytes) disk size: 18G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
- OSPDが失われる問題を回避するには、QCOW2形式で最近作成したスナップショットを外部エンティティに転送する必要があります。ファイル転送を開始する前に、宛先に十分な空きディスク領域があるかどうかを確認し、コマンドdf -khを実行してメモリ領域を確認する必要があります。アドバイスの1つは、SFTP sftp root@x.x.x.xを使用して別のサイトのOSPDに一時的に転送することです。 x.x.x.xはリモートOSPDのIPです。転送を高速化するために、宛先を複数のOSPDに送信できます。同じ方法でscp *name_of_the_file*.qcow2 root@ x.x.x.x.x:/tmp （x.x.x.xはリモートOSPDのIP）コマンドを実行して、ファイルを別のOSPDに転送できます。
- OSDコンピューティングノードでホストされるVMを特定します。
- サーバでホストされているVMを特定します。
[stack@director ~]$ nova list --field name,host | grep osd-compute-0 | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |
- 単一のOSDサーバを削除できるように、CEPHに使用可能な容量があることを確認します。
[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df GLOBAL: SIZE AVAIL RAW USED %RAW USED 13393G 11088G 2305G 17.21 POOLS: NAME ID USED %USED MAX AVAIL OBJECTS rbd 0 0 0 3635G 0 metrics 1 3452M 0.09 3635G 219421 images 2 138G 3.67 3635G 43127 backups 3 0 0 3635G 0 volumes 4 139G 3.70 3635G 36581 vms 5 490G 11.89 3635G 126247
- ceph osdツリーのステータスがosdコンピュートサーバでアップしていることを確認します。
[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 13.07996 root default -2 4.35999 host pod2-stack-osd-compute-0 0 1.09000 osd.0 up 1.00000 1.00000 3 1.09000 osd.3 up 1.00000 1.00000 6 1.09000 osd.6 up 1.00000 1.00000 9 1.09000 osd.9 up 1.00000 1.00000 -3 4.35999 host pod2-stack-osd-compute-1 1 1.09000 osd.1 up 1.00000 1.00000 4 1.09000 osd.4 up 1.00000 1.00000 7 1.09000 osd.7 up 1.00000 1.00000 10 1.09000 osd.10 up 1.00000 1.00000 -4 4.35999 host pod2-stack-osd-compute-2 2 1.09000 osd.2 up 1.00000 1.00000 5 1.09000 osd.5 up 1.00000 1.00000 8 1.09000 osd.8 up 1.00000 1.00000 11 1.09000 osd.11 up 1.00000 1.00000
- CEPHプロセスはosd-computeサーバ上でアクティブです。
[heat-admin@pod2-stack-osd-compute-0 ~]$ systemctl list-units *ceph* UNIT LOAD ACTIVE SUB DESCRIPTION var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0 var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3 var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6 var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9 ceph-osd@0.service loaded active running Ceph object storage daemon ceph-osd@3.service loaded active running Ceph object storage daemon ceph-osd@6.service loaded active running Ceph object storage daemon ceph-osd@9.service loaded active running Ceph object storage daemon system-ceph\x2ddisk.slice loaded active active system-ceph\x2ddisk.slice system-ceph\x2dosd.slice loaded active active system-ceph\x2dosd.slice ceph-mon.target loaded active active ceph target allowing to start/stop all ceph-mon@.service instances at once ceph-osd.target loaded active active ceph target allowing to start/stop all ceph-osd@.service instances at once ceph-radosgw.target loaded active active ceph target allowing to start/stop all ceph-radosgw@.service instances at once ceph.target loaded active active ceph target allowing to start/stop all ceph*@.service instances at once LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type.
14 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
- 各cephインスタンスを無効にして停止し、各インスタンスをosdから削除して、ディレクトリをアンマウントします。cephインスタンスごとに繰り返します。
[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl disable ceph-osd@0 [heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0 [heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0
- osd.0がマークされました。
[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0
- クラッシュマップから項目id 0名「osd.0」を削除
[heat-admin@pod2-stack-osd-compute-0 ~]# ceph auth del osd.0
- updated
[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0
- osd.0の削除
[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0 [heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0
または、
- Clean.shスクリプトは、このタスクに一度に使用できます。
[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd ceph-0 ceph-3 ceph-6 ceph-9
[heat-admin@pod2-stack-osd-compute-0 ~]$ /bin/sh clean.sh [heat-admin@pod2-stack-osd-compute-0 ~]$ cat clean.sh
#!/bin/sh set -x CEPH=`sudo ls /var/lib/ceph/osd` for c in $CEPH do i=`echo $c |cut -d'-' -f2` sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1) sleep 2 sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph osd out $i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph osd rm $i || (echo "error rc:$?"; exit 1) sleep 2 sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1) sleep 2 sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1) sleep 2 done sudo ceph osd tree
すべてのOSDプロセスが移行/削除されると、ノードをオーバークラウドから削除できます。
グレースフルパワーオフ
- ノードの電源オフ
- インスタンスの電源をオフにするには：nova stop <INSTANCE_NAME>
- インスタンス名は、ステータスシャットオフで確認できます。
[stack@director ~]$ nova stop aaa2-21 Request to stop server aaa2-21 has been accepted. [stack@director ~]$ nova list +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+ | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE | - | Running | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 | | 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21 | SHUTOFF | - | Shutdown | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234 | | f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june | ACTIVE | - | Running | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10 | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+
- ノードの削除
このセクションで説明する手順は、コンピューティングノードでホストされるVMに関係なく共通できます。
サービス・リストからOSDコンピュート・ノードを削除します。
- サービスリストからコンピュートサービスを削除します。
[stack@director ~]$ openstack compute service list |grep osd-compute | 135 | nova-compute | pod2-stack-osd-compute-1.localdomain | AZ-esc2 | enabled | up | 2018-06-22T11:05:22.000000 | | 150 | nova-compute | pod2-stack-osd-compute-2.localdomain | nova | enabled | up | 2018-06-22T11:05:17.000000 | | 153 | nova-compute | pod2-stack-osd-compute-0.localdomain | AZ-esc1 | enabled | up | 2018-06-22T11:05:25.000000 |
- openstack 計算 service delete <ID>
[stack@director ~]$ openstack compute service delete 150
Neutronエージェントの削除
- 古い関連付けられたNeutronエージェントを削除し、ComputerServerのvswitchエージェントを開きます。
[stack@director ~]$ openstack network agent list | grep osd-compute-0 | eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None | True | UP | neutron-openvswitch-agent |
- openstack network agent delete <ID>
[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22
Ironicデータベースから削除
- 皮肉なデータベースからノードを削除し、確認します。
[root@director ~]# nova list | grep osd-compute-0 | 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.109 | [root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f
- nova show <compute -node> | grep hypervisor
[root@director ~]# source stackrc [root@director ~]# nova show pod2-stack-osd-compute-0 | grep hypervisor | OS-EXT-SRV-ATTR:hypervisor_hostname | 05ceb513-e159-417d-a6d6-cbbcc4b167d7
- ironic node-delete <ID>
[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7 [stack@director ~]$ ironic node-list
削除されたノードを皮肉なノードリストにリストすることはできません。
オーバークラウドから削除
- 次に示すように、内容を含む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-name> <UUID>
[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 pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444 Deleting the following nodes from stack pod2-stack: - 7439ea6c-3a88-47c2-9ff5-0a4f24647444 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 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z | +--------------------------------------+------------+-----------------+----------------------+----------------------+
新しいコンピューティングノードのインストール
- 新しいUCS C240 M4サーバをインストールする手順と初期セットアップ手順は、次から参照できます。
『Cisco UCS C240 M4 Server Installation and Service Guide』
- サーバのインストールが完了したら、ハードディスクを古いサーバとしてそれぞれのスロットに挿入します。
- CIMC IPを使用してサーバにログインします。
- ファームウェアが以前に使用した推奨バージョンと異なる場合は、BIOSアップグレードを実行します。BIOSアップグレードの手順は次のとおりです。
Cisco UCS CシリーズラックマウントサーバBIOSアップグレードガイド
- 物理ドライブのステータスを確認します。構成を解除する必要があります。
次の図に示すように、[Storage] > [Cisco 12G SAS Modular Raid Controller (SLOT-HBA)] > [Physical Drive Info]に移動します。
- RAIDレベル1の物理ドライブから仮想ドライブを作成します。
次の図に示すように、[Storage] > [Cisco 12G SAS Modular Raid Controller (SLOT-HBA)] > [Controller Info] > [Create Virtual Drive from Unused Physical Drives]に移動します。
- VDを選択し、図に示すように[Set as Boot Drive]を設定します。
- IPMI over LANの有効化：
図に示すように、[Admin] > [Communication Services] > [Communication Services]に移動します。
- ハイパースレッディングを無効にします。
図に示すように、[Compute] > [BIOS] > [Configure BIOS] > [Advanced] > [Processor Configuration]に移動します。
- 物理ドライブ1および2で作成されたBOOTOS VDと同様に、次の4つの仮想ドライブを作成します。
JOURNAL > From physical drive number 3 OSD1 > From physical drive number 7 OSD2 > From physical drive number 8 OSD3 > From physical drive number 9 OSD4 > From physical drive number 10
- 最後に、物理ドライブと仮想ドライブは、図に示すように類似している必要があります。
Overcloudへの新しいOSDコンピューティングノードの追加
このセクションで説明する手順は、コンピューティングノードによってホストされるVMに関係なく共通しています。
- 別のインデックスを持つコンピューティングサーバーを追加します。
追加する新しいコンピュートサーバの詳細のみを含むadd_node.jsonファイルを作成します。新しいコンピュートサーバのインデックス番号が以前に使用されていないことを確認します。通常は、次に高い計算値を増やします。
例：最も前のバージョンはosd-compute-17で、2-vnfシステムの場合はosd-compute-18が作成されました。
[stack@director ~]$ cat add_node.json
{
"nodes":[
{
"mac":[
"<MAC_ADDRESS>"
],
"capabilities": "node:osd-compute-3,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 |
- IPアドレスをcustom-templates/layout.ymlのOsd Compute IPsに追加します。この場合、osd-compute-0を置き換えて、各タイプのリストの最後にそのアドレスを追加します
OsdComputeIP:
internal_api:
- 11.120.0.43
- 11.120.0.44
- 11.120.0.45
- 11.120.0.43 <<< take osd-compute-0 .43 and add here
tenant:
- 11.117.0.43
- 11.117.0.44
- 11.117.0.45
- 11.117.0.43 << and here
storage:
- 11.118.0.43
- 11.118.0.44
- 11.118.0.45
- 11.118.0.43 << and here
storage_mgmt:
- 11.119.0.43
- 11.119.0.44
- 11.119.0.45
- 11.119.0.43 << and here
- 新しいコンピュートノードをオーバークラウドスタックに追加するには、スタックの展開に以前に使用した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 osd-compute-3 | 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3 | ACTIVE | - | Running | ctlplane=192.200.0.117 | [stack@director ~]$ source corerc [stack@director ~]$ openstack hypervisor list |grep osd-compute-3 | 63 | pod1-osd-compute-3.localdomain |
- 新しいosd-compute serverにログインし、cephプロセスを確認します。最初は、cephが回復したため、ステータスはHEALTH_WARNです。
-
[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s cluster eb2bb192-b1c9-11e6-9205-525400330666 health HEALTH_WARN 223 pgs backfill_wait 4 pgs backfilling 41 pgs degraded 227 pgs stuck unclean 41 pgs undersized recovery 45229/1300136 objects degraded (3.479%) recovery 525016/1300136 objects misplaced (40.382%) monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0} election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2 osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs flags sortbitwise,require_jewel_osds pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects 1553 GB used, 11840 GB / 13393 GB avail 45229/1300136 objects degraded (3.479%) 525016/1300136 objects misplaced (40.382%) 477 active+clean 186 active+remapped+wait_backfill 37 active+undersized+degraded+remapped+wait_backfill 4 active+undersized+degraded+remapped+backfilling - ただし、短時間（20分）の後、CEPHはHEALTH_OK状態に戻ります。
[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s
cluster eb2bb192-b1c9-11e6-9205-525400330666 health HEALTH_OK monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0} election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2 osdmap e1398: 12 osds: 12 up, 12 in flags sortbitwise,require_jewel_osds pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects 1599 GB used, 11793 GB / 13393 GB avail 704 active+clean client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 13.07996 root default -2 0 host pod1-osd-compute-0 -3 4.35999 host pod1-osd-compute-2 1 1.09000 osd.1 up 1.00000 1.00000 4 1.09000 osd.4 up 1.00000 1.00000 7 1.09000 osd.7 up 1.00000 1.00000 10 1.09000 osd.10 up 1.00000 1.00000 -4 4.35999 host pod1-osd-compute-1 2 1.09000 osd.2 up 1.00000 1.00000 5 1.09000 osd.5 up 1.00000 1.00000 8 1.09000 osd.8 up 1.00000 1.00000 11 1.09000 osd.11 up 1.00000 1.00000 -5 4.35999 host pod1-osd-compute-3 0 1.09000 osd.0 up 1.00000 1.00000 3 1.09000 osd.3 up 1.00000 1.00000 6 1.09000 osd.6 up 1.00000 1.00000 9 1.09000 osd.9 up 1.00000 1.00000
VMの復元
スナップショットによるインスタンスのリカバリ
前のステップで実行したスナップショットを使用して、前のインスタンスを再展開できます。
ステップ1:（オプション）使用可能な以前のVMスナップショットがない場合は、バックアップが送信されたOSPDノードに接続し、バックアップを元のOSPDノードにSFTPして戻します。sftp root@x.x.x.xwhere x.x.x.xは元のOSPDのIPです。スナップショットファイルを/tmpディレクトリに保存します。
ステップ2：インスタンスが再配置されるOSPDノードに接続します。
次のコマンドを使用して、環境変数をソース化します。
# source /home/stack/pod1-stackrc-Core-CPAR
ステップ3：スナップショットをイメージとして使用するには、必要に応じて地平線にアップロードする必要があります。次のコマンドを実行して、実行します。
#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot
このプロセスは、次の図に示すように水平線で確認できます。
ステップ4：次の図に示すように、[Horizon]で[Project] > [インスタンス]に移動し、[インスタンスをロード]をクリックします。
ステップ5：インスタンス名を入力し、次の図に示す[Availability Zone]を選択します。
ステップ6:[Source]タブでイメージを選択して、インスタンスを作成します。[ブートソースの選択]メニューでイメージを選択して、イメージのリストを表示して、+記号をクリックしてアップロードしたイメージを選択します。次の図を参照してください。
ステップ7:[Flavor]タブで、次の図に示すように+記号をクリックしてAAAフレーバーを選択します。
ステップ8：最後に、[Network]タブに移動し、+記号をクリックしてインスタンスに必要なネットワークを選択します。この場合は、次の図に示すように、diameter-soutable1、radius-routable1、およびtb1-mgmtを選択します。
ステップ9：最後に、[Launch Instance]をクリックして作成します。次の図に示すように、Horizonで進行状況を監視できます。
数分後に、インスタンスが完全に導入され、使用可能な状態になります。
フローティングIPアドレスの作成と割り当て
フローティングIPアドレスは、ルーティング可能なアドレスです。つまり、Ultra M/Openstackアーキテクチャの外部から到達可能であり、ネットワークの他のノードと通信できます。
ステップ1:[Horizon]トップメニューで、[Admin] > [Floating IPs]に移動します。
ステップ2:[Allocate IP to Project]をクリックします。
ステップ3:「フローティングIPの割り当て」ウィンドウで、新しいフローティングIPが属するプール、割り当て先のプロジェクト、新しいフローティングIPアドレスを選択します。
以下に、いくつかの例を示します。
ステップ4:[Allocate Floating IP]をクリックします。
ステップ5:[Horizon]トップメニューで、[Project] > [Instances]に移動します。
ステップ6:[アクション]列で、[スナップショットの作成]ボタンを下に向く矢印をクリックすると、メニューが表示されます。[Associate Floating IP]オプションを選択します。
ステップ7:[IP Address]フィールドで使用する対応するフローティングIPアドレスを選択し、関連付けるポートでこのフローティングIPが割り当てられる新しいインスタンスから対応する管理インターフェイス(eth0)を選択します。
ステップ8：最後に、[Associate]をクリックします。
SSH の有効化
ステップ1:[Horizon]トップメニューで、[Project] > [Instances]に移動します。
ステップ2：セクション「新規インスタンスのランチ」で作成したインスタンス/VMの名前をクリックします。
ステップ3:[Console]をクリックします。これにより、VMのCLIが表示されます。
ステップ4:CLIが表示されたら、適切なログインクレデンシャルを入力します。
ユーザ名:root
パスワード：cisco123を参照してください。
ステップ5:CLIでコマンドvi /etc/ssh/sshd_configを実行して、ssh設定を編集します。
ステップ6:SSH設定ファイルが開いたら、Iを押して編集します。次に、ここに示すセクションを探し、最初の行をPasswordAuthentication noからPasswordAuthentication yesに変更します。
ステップ7: Escキーを押して:wq!sshd_configファイルの変更を保存します。
ステップ8：コマンドservice sshd restartを実行します。
ステップ9:SSH設定の変更が正しく適用されたことをテストするために、任意のSSHクライアントを開き、インスタンスに割り当てられたフローティングIP(10.145.0.249)とユーザrootを使用してリモート安全接続ををを確立します。
SSHセッションの確立
ステップ1：次の図に示すように、アプリケーションがインストールされている対応するVM/サーバのIPアドレスでSSHセッションを開きます。
CPARインスタンス開始
アクティビティが完了し、シャットダウンされたサイトでCPARサービスを再確立できたら、次の手順に従います。
ステップ1：ホライズンにログインし、[プロジェクト] > [インスタンス] > [インスタンスの開始]に移動します。
ステップ2：次の図に示すように、インスタンスのステータスがActiveで、電源状態がRunningであることを確認します。
アクティビティ後のヘルスチェック
ステップ1:OSレベルでコマンド/opt/CSCOar/bin/arstatusを実行します。
[root@wscaaa04 ~]# /opt/CSCOar/bin/arstatus Cisco Prime AR RADIUS server running (pid: 24834) Cisco Prime AR Server Agent running (pid: 24821) Cisco Prime AR MCD lock manager running (pid: 24824) Cisco Prime AR MCD server running (pid: 24833) Cisco Prime AR GUI running (pid: 24836) SNMP Master Agent running (pid: 24835) [root@wscaaa04 ~]#
ステップ2：コマンド/opt/CSCOar/bin/aregcmdをOSレベルで実行し、管理者クレデンシャルを入力します。CPAr Healthが10のうち10で、CPAR CLIを終了していることを確認します。
[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc. All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]
LicenseInfo = PAR-NG-TPS 7.2(100TPS:)
PAR-ADD-TPS 7.2(2000TPS:)
PAR-RDDR-TRX 7.2()
PAR-HSS 7.2()
Radius/
Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit
ステップ3：コマンドnetstatを実行する | grep diameterとして、すべてのDRA接続が確立されていることを確認します。
ここで説明する出力は、Diameterリンクが必要な環境を対象としています。表示されるリンク数が少ない場合は、分析が必要なDRAからの切断を表します。
[root@aa02 logs]# netstat | grep diameter tcp 0 0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED
ステップ4:TPSログに、CPARによって処理されている要求が表示されることを確認します。強調表示された値はTPSを表し、これらは注意が必要な値です。
TPSの値は1500を超えることはできません。
[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv 11-21-2017,23:57:35,263,0 11-21-2017,23:57:50,237,0 11-21-2017,23:58:05,237,0 11-21-2017,23:58:20,257,0 11-21-2017,23:58:35,254,0 11-21-2017,23:58:50,248,0 11-21-2017,23:59:05,272,0 11-21-2017,23:59:20,243,0 11-21-2017,23:59:35,244,0 11-21-2017,23:59:50,233,0
ステップ5:name_radius_1_logで「error」または「alarm」メッセージを探します。
[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log
ステップ6:CPARプロセスが使用したメモリ量を確認するには、次のコマンドを実行します。
top | grep radius
[root@sfraaa02 ~]# top | grep radius 27008 root 20 0 20.228g 2.413g 11408 S 128.3 7.7 1165:41 radius
この強調表示された値は、アプリケーションレベルで許可される最大値である7 Gbより小さい必要があります。
フィードバック