はじめに

私たちのチームでは、OpenStackを活用して利用者に仮想環境を提供しています。OpenStackは、オープンソースソフトウェア(OSS)のクラウド・コンピューティング・プラットフォームです。仮想環境上でのマシン、ストレージ、ネットワークなどのリソースを統合管理できるインフラストラクチャを提供します。私たちはこのOpenStackをオンプレミス環境で数年前に導入しました。しかし、当時購入したサーバーの保守期限が近づいていたため、これを機にサーバーの更改作業を進めることになりました。前回に引き続き、この記事ではblockノードのサーバー更改中に発生したトラブルと、その対応内容について紹介します。

サーバー更改の概要

既存OpenStack環境

構築当初のOpenStackのバージョンはMitakaでしたが、その後バージョンアップを行い更改当時はQueensを使用していました。ノードの構成は以下のとおりです。

OpenStackのblockノードの主なコンポーネントはCinder^※1になります。CinderのバックエンドにはCeph^※2を使用しています。

※1：OpenStackが提供するブロック・ストレージ・サービスです。仮想マシンに対して永続的なブロックストレージを提供し、データの読み書きを行うためのインターフェースを実現します。ユーザーは、ボリュームの作成、スナップショットの管理、ボリュームのアタッチとデタッチを簡単に行うことができます。詳細についてはOpenStack公式 ⧉を参照してください。
※2：OSSの分散ストレージソフトウェアです。OpenStackのCinderと連携して高可用性、冗長性、スケーラビリティーを提供します。詳細についてはOpenStack環境でBlockストレージを増設する - 基礎知識編を参照してください。

OS選定と更改方針

OSは「Ubuntu」を採用しました。選定理由は以下のとおりです。OSのバージョンに関する詳細は、前回の記事を参照してください。

サーバー更改後の構成は以下のとおりです。

blockノードは初期構築時には3台で構成されていましたが、その後、運用の拡張に伴い1台を追加しており、サーバーの保守期限が異なるため今回の更改対象は3台となります。この結果、旧blockノードと新blockノードではOSバージョンが異なるため、互換性に注意が必要です。

更改方法

OpenStackで作成したボリュームは、バックエンドのCephによって複数のblockノードに分散して格納されます。この際、ボリュームが管理されるblockノードはいずれか1台のノードに関連付けられます。そのため、ボリュームの管理ノードを移行する必要があり、構築当初の手順書とOpenStack公式 ⧉の手順を参考に、以下の手順で移行を計画しました。まず、新blockノードをOpenStack環境に追加します。その後、旧blockノードが管理しているボリュームの管理ノードを新blockノードに移行し、最後に旧blockノードをOpenStackから削除します。この手順を繰り返し、すべてのボリュームの移行を完了させる計画です。

移行対象ボリューム

旧blockノードが管理ノードとなっている以下の全てのボリュームの管理ノードを新blockノードに移行する必要があります。

※3：OpenStackが提供するデータベースサービスです。データベースのデプロイ、管理、スケーリングを簡単に実行できる仕組みを提供します。詳細についてはOpenStack公式 ⧉を参照してください。
※4：OpenStackが提供する共有ファイル・システム・サービスです。仮想マシンやアプリケーションが利用可能な共有ファイルシステムの作成、管理をサポートします。詳細についてはOpenStack公式 ⧉を参照してください。

移行方法

ボリュームの数が多いため、openstackコマンドを用いたスクリプトを作成し、移行作業を自動化します。このスクリプトは、利用者へのサービス影響を最小限に抑えるために、atコマンドを使用し、夜間に実行します。

【スクリプトの処理内容】

1. ボリュームの状態を確認する。
2. ボリュームがインスタンスにアタッチされている場合、インスタンスの状態を確認する。
3. インスタンスの状態が起動状態の場合、インスタンスを停止状態にする。
4. インスタンスからボリュームをデタッチする。
5. 指定したblockノードにボリュームを移行する。
6. 2.でボリュームがインスタンスにアタッチされていた場合、インスタンスにボリュームをアタッチする。
7. 3.でインスタンスの状態が起動状態だった場合、インスタンスを起動状態にする。
8. 上記1～7の処理を全ボリュームについて繰り返す。

スクリプトで使用するopenstackコマンドは以下のとおりです。

トラブルシューティングで説明しますが、この移行方法で問題が発生したため、スクリプトは使用しませんでした。

トラブルシューティング

ボリュームの移行ができない

検証環境でopenstack volume migrateコマンドを実行した結果、エラーは表示されなかったもののボリュームの移行には失敗しました。

1
# openstack volume show 6727920d-aec0-4eea-ac73-20aa766a4b40
2
+--------------------------------+--------------------------------------+
3
| Field                          | Value                                |
4
+--------------------------------+--------------------------------------+
5
:
6
| id                             | 6727920d-aec0-4eea-ac73-20aa766a4b40 |
7
:
8
| os-vol-host-attr:host          | block2@ceph#ceph                     |
9
:
10
# openstack volume migrate --host block202dev@ceph 6727920d-aec0-4eea-ac73-20aa766a4b40
11
# openstack volume show 6727920d-aec0-4eea-ac73-20aa766a4b40
12
+--------------------------------+--------------------------------------+
13
| Field                          | Value                                |
14
+--------------------------------+--------------------------------------+
15
:
16
| id                             | 6727920d-aec0-4eea-ac73-20aa766a4b40 |
17
:
18
| os-vol-host-attr:host          | block2@ceph#ceph                     |
19
:

そこで、問題解決のためにcinderコマンドを調査したところ、ボリューム移行に関連するcinder migrateコマンドを見つけました。このコマンドを使って再度ボリュームの移行を試みましたが、同様にエラーメッセージは表示されず、ボリュームの移行も成功しませんでした。さらにcinder関連のコマンドを調査していると、cinder-manage volume update_hostというコマンドが存在することに気付きました。このコマンドは、--currenthostオプションで現在の管理ノードを指定し、--newhostオプションで新しい管理ノードを指定することで、ボリュームの管理ノードを変更できます。実際にこのコマンドを実行したところ、ボリュームの管理ノードが無事に移行されました。

1
# cinder migrate 6727920d-aec0-4eea-ac73-20aa766a4b40 block202dev@ceph
2
# openstack volume show 6727920d-aec0-4eea-ac73-20aa766a4b40
3
+--------------------------------+--------------------------------------+
4
| Field                          | Value                                |
5
+--------------------------------+--------------------------------------+
6
:
7
| id                             | 6727920d-aec0-4eea-ac73-20aa766a4b40 |
8
:
9
| os-vol-host-attr:host          | block2@ceph#ceph                     |
10
:
11
# cinder-manage volume update_host --currenthost block2@ceph --newhost block202dev@ceph
12
# openstack volume show 6727920d-aec0-4eea-ac73-20aa766a4b40
13
+--------------------------------+--------------------------------------+
14
| Field                          | Value                                |
15
+--------------------------------+--------------------------------------+
16
:
17
| id                             | 6727920d-aec0-4eea-ac73-20aa766a4b40 |
18
:
19
| os-vol-host-attr:host          | block202dev@ceph                     |
20
:

この操作はボリューム単位ではなく、ノード単位での移行が可能であるため、移行方法で説明した当初予定していたスクリプトによる夜間実行ではなく、更改作業の中で手動によるコマンド実行としました。

CephのOSD IDが若番から採番される

Cephはオープンソースの分散ストレージシステムで、柔軟性と拡張性が高い特徴を持っています。CephのOSD(Object Storage Device)は、通常、1つの物理ディスクまたはパーティションを管理します。OSDは、Cephストレージクラスター内でデータオブジェクトを保存し、データの読み取り、書き込み、レプリケーションを行います。今回更改する各blockノードには、Cephのデータを格納するためのディスクが6つあります。それに対して、OSDはそれぞれ6つ構成されており、これによりストレージの冗長性とスケーラビリティーが確保されています。具体的には、複数のOSDが協力し合ってデータの管理を行い、どのOSDが故障してもデータが失われないように設計されています。当環境のCephのバージョンはJewelです。OSDの追加はceph-deploy osd prepareコマンドを使用して、新しいOSDを準備します。OSDの削除にはceph osd rmコマンドを使用して、不要になったOSDをクラスターから削除します。

検証環境で新blockノード1にOSDを追加すると、新blockノード1にOSD IDは24~29が採番されました。

旧blockノード1のOSDを削除すると、旧blockノード1に割り当てられていたOSD IDの0~5がなくなりました。

新blockノード2にOSDを追加すると、新blockノード2にOSD IDが若番の0~5で採番されました。

私たちの期待としては、以下のように新しいblockノード2に対してOSD IDが連番で採番されることでした。

旧blockノード1のOSDを削除したことで、OSD IDが空きとなり、その空いたIDが新しいblockノードに採番されてしまったようです。運用上は特に問題はありませんが、管理上、途中から空きになったOSD IDが採番されてしまうことは避けたかったため、当初予定していた更改方法を変更しました。具体的には、すべての新blockノードでOSDを追加した後に、旧blockノードのOSDを削除する方法を採用することにしました。

ボリュームがアタッチされたインスタンスが起動できない

この問題は以前から認識していましたが、インスタンスにアタッチされたボリュームが特定の条件を満たすと、インスタンスを停止し、再び起動した際に起動できないことがありました。この条件とは、Novaのblock_device_mappingテーブル(ボリュームの情報を管理するテーブル)のconnection_infoカラム(ボリュームにアクセスするために必要な接続情報が格納されたカラム)に含まれるCeph Monitorの情報に、変更後のblockノードの情報が含まれないことになります。ただし、この条件下でもWindowsメニューからの再起動、Linuxのrebootコマンド、OpenStackダッシュボードのインスタンスのソフトリブートなど、通常の再起動方法ではインスタンスは正しく起動することができます。block_device_mappingのレコードは、インスタンスにボリュームをアタッチする際に作成され、その時点のCeph Monitorの情報がconnection_infoカラムのフィールドに保持されます。一方、ボリュームをデタッチすると、そのレコードは削除されます。Ceph Monitorは、OSDクラスター全体の状態を管理し、ファイルシステムやblockノードの情報を集約して一元的に監視を行います。私たちの環境では各blockノードにCeph Monitorを配置しています。そのため、私たちの環境におけるCeph Monitorの情報の組み合わせは、構築時期によって異なり、次のようになります。

初期構築時にボリュームをアタッチしたインスタンスを、今回のサーバー更改後に、インスタンスを停止して、再び起動すると同様の事象が発生することになります。インスタンスからボリュームをデタッチしてアタッチすることでこの問題を回避することは可能ですが、利用者に作業影響が出ることを考慮しました。そこで、Novaのblock_device_mappingテーブルのconnection_infoカラムをSQLを用いて初期構築時のCeph Monitor情報から今回のサーバー更改時の状態に変更しました。

変更前：192.168.1.XX、192.168.1.YY、192.168.1.ZZは旧blockノードのIPアドレス

1
{
2
  "driver_volume_type": "rbd",
3
  "connector": {
4
    "initiator": "iqn.1994-05.com.redhat:ad82a7d845b8",
5
    "ip": "192.168.1.AA",
6
    "platform": "x86_64",
7
    "host": "compute",
8
    "do_local_attach": false,
9
    "os_type": "linux2",
10
    "multipath": false
11
  },
12
  "serial": "53378c48-6475-4e2b-92e6-39285bb9a0b1",
13
  "data": {
14
    "secret_type": "ceph",
15
    "name": "volumes/volume-53378c48-6475-4e2b-92e6-39285bb9a0b1",
16
    "encrypted": false,
17
    "keyring": null,
18
    "cluster_name": "ceph",
19
    "secret_uuid": "fd3012f4-a00c-4925-9b19-ce975271837a",
20
    "qos_specs": null,
21
    "auth_enabled": true,
22
    "hosts": [
23
      "192.168.1.XX",
24
      "192.168.1.YY",
25
      "192.168.1.ZZ"
26
    ],
27
    "volume_id": "53378c48-6475-4e2b-92e6-39285bb9a0b1",
28
    "discard": true,
29
    "access_mode": "rw",
30
    "auth_username": "cinder",
31
    "ports": [
32
      "6789",
33
      "6789",
34
      "6789"
35
    ]
36
  }
37
}

変更後：192.168.1.aa、192.168.1.bb、192.168.1.ccは新blockノードのIPアドレス

1
{
2
  "driver_volume_type": "rbd",
3
  "connector": {
4
    "initiator": "iqn.1994-05.com.redhat:ad82a7d845b8",
5
    "ip": "192.168.1.AA",
6
    "platform": "x86_64",
7
    "host": "compute",
8
    "do_local_attach": false,
9
    "os_type": "linux2",
10
    "multipath": false
11
  },
12
  "serial": "53378c48-6475-4e2b-92e6-39285bb9a0b1",
13
  "data": {
14
    "secret_type": "ceph",
15
    "name": "volumes/volume-53378c48-6475-4e2b-92e6-39285bb9a0b1",
16
    "encrypted": false,
17
    "keyring": null,
18
    "cluster_name": "ceph",
19
    "secret_uuid": "fd3012f4-a00c-4925-9b19-ce975271837a",
20
    "qos_specs": null,
21
    "auth_enabled": true,
22
    "hosts": [
23
      "192.168.1.AAA",
24
      "192.168.1.aa",
25
      "192.168.1.bb",
26
      "192.168.1.cc"
27
    ],
28
    "volume_id": "53378c48-6475-4e2b-92e6-39285bb9a0b1",
29
    "discard": true,
30
    "access_mode": "rw",
31
    "auth_username": "cinder",
32
    "ports": [
33
      "6789",
34
      "6789",
35
      "6789",
36
      "6789"
37
    ]
38
  }
39
}

ここで、Ceph Monitorの情報はdataセクション内のhostsとportsの部分になります。この部分を変更するSQLを実行します。今後、旧blockノード4を更改するときには、1台追加時の情報も同様に対処が必要になります。

おわりに

この記事では、OpenStackのblockノードを更改した際に発生したトラブルへの対応内容を紹介しました。この記事が、OpenStackを運用されている方や、これから導入やサーバー更改を検討される方々のお役に立てば幸いです。今後、controllerノードやnetworkノードなど、他のノードの移行に関するノウハウについても順次紹介していく予定です。