0

NFV基盤で利用しているCephクラスタのバージョンアップを内製対応した話
KDDI株式会社 松本 良輔、齋藤 裕子

本発表でお話しすること

1◼ KDDIではOpenStackとCephを用いて、音声通信設備のためのNFV仮想化基盤を構築(※)しています。

◼ この仮想化基盤においてCephのバージョンアップを内製で実施しました。
◼ 本発表では、直面した課題をどう解決したか、効率的な手順検証とメンバーのスキルアップを両立させた点について紹介します。
【※過去発表】CODT2020:そういやNFVってどうなったん？最近あまり聞かなかくなったNFVの話（KDDI編）(https://cloudopsdays.com/archive/2020/program/)
CODT2021:NFVでクラウドネイティブに変わる電話会社の運用（KDDI編）(https://cloudopsdays.com/archive/2021/sessions/)
JANOG49 :KDDI固定電話ネットワーク、NFV化の5年間の道のり(https://www.janog.gr.jp/meeting/janog49/kddinfv/)
CODT2022: OpenStack NFV基盤のバージョンアップと運用改善を内製対応した話(https://cloudopsdays.com/archive/2022/ondemand/)発表者紹介2

ネットワーク開発本部

キャリアクラウド開発部

松本 良輔
前半
ネットワーク開発本部

キャリアクラウド開発部

齋藤 裕子
後半

アジェンダ3

1

オンラインセッション部分のおさらい

2

作業時間短縮のために実施した工夫

3OA

4

1. NFV基盤について

NFV基盤について

5

OSSを活用したベンダニュートラルな仮想化基盤を構築

OpenStack＋Cephで仮想化基盤を構築

様々な音声サービスを提供するVMを構築。商用サービス開始中

OpenStack

Volume…

VolumeVolumeＶＡ ＶＡ ＶＢ ＶＣ
Ｍ社 Ｍ社 Ｍ社 Ｍ社

Ceph
HW…

KDDI
IP電話網

他社網
移動体網

6

2. Cephのバージョンアップ概要と直面した課題

当初思い描いていた手順 Cephバージョンアップ
各ノードのOSとコンテナを以下にCephクラスタ

MONRHEL8.2 ⇒ RHEL8.6
Ceph(Nautilus)マイナーバージョンアップ

MGR MONRGW
RHEL8.2
MON
RHEL8.2
MON(RHEL8.2)

Zone-A

Zone-B

Zone-C

OSD(x10)1OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

１台ずつクラスタから切り離しながら・・・➢ OSはansible-playbookを使って1台ずつバージョン
アップ➢ コンテナはceph-ansible-playbookのrolling_updateを使い、Limitオプションを付けて１コンテナずつバージョンアップ

(スモールスタート)

7当初思い描いていた手順 Cephバージョンアップ

8Cephクラスタ
MONMON

Zone-A

MGR MONRGW
RHEL8.2
MON
RHEL8.2MON(RHEL8.2)

Zone-BMONRHEL8.2
MON
RHEL8.2
MON
RHEL8.6

MONを1台ずつ
Zone-C

１．OSをRHEL8.2からRHEL8.6へバージョンアップ
２．MONコンテナのイメージを置換えてバージョンアップ

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

MONMONMGR
RHEL8.2
MON
RHEL8.2
MON
RHEL8.6

３．MGRコンテナのイメージを置換えてバージョンアップ

当初思い描いていた手順 Cephバージョンアップ
CephクラスタMON

OSD(x10)OSD
RHEL8.6

MGR MONRGW
RHEL8.2
MON
RHEL8.2MON(RHEL8.2)

Zone-A

Zone-B

Zone-C

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSDを1台ずつ
４．クラスタから切り離し
５．OSをRHEL8.2からRHEL8.6へバージョンアップ
６．OSDコンテナのイメージを置換えてバージョンアップ

MON------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

MGR MON RGW
RHEL8.2
MON
RHEL8.2
MON
RHEL8.6

６．RGWコンテナのイメージを置換えてバージョンアップ

9

問題発生

10

前述の手順でやりたかったけれど・・・とある問題のせいでできない。。。

バージョンアップする際の問題

11

今回対象バージョン間のアップグレードに際し一部機能(RGW)においてバージョンアップ最中の互換性が失われているような変更が入っていた
OSDを先にバージョンアップした場合
OSDバージョン
アップ前に保存されたデータ
RGW(旧Ver)

OSD(新Ver)
OSDバージョン
アップ後に保存されたデータ

RGWが新しいコードを理解できず、バージョンアップ後に保存されたデータがクラッシュする可能性があったバージョンアップする際の問題

12では、RGWを先にバージョンアップしたら？
RGWを先にバージョンアップした場合新しい実装を利用してOSDにアクセス
RGW(新Ver)

OSD(旧Ver)OSDはRGW側の新しい実装によるメッセージを理解できず誤ったレスポンスを返す

バージョンアップする際の問題

どちらも選べない・・・
公式手順は前述の問題回避として、OSD/RGW間のバージョン差異期間を出来るだけ短くするため、一気にバージョンアップするものとなっていた
しかし、当基盤上には総務省報告対象となるサービスが動いていたため、社内承認上、上記のやり方は選択できなかった（原則スモールスタート）

Step by stepの手順を確立する必要があった

13

14

3. どのように課題を解決したか課題解決に向けてバージョンアップ前にRGWの機能を既存クラスタから切り離せばいいのでは？

15

課題の対策(1/3)

16

テナントからのAPIリクエスト

HAproxy

1) 暫定Cephクラスタを既存と同バージョンのVMで構築

RGW

RGW

RGW

MON
RHEL8.2

MONRHEL8.2

MON
RHEL8.2

RGW

RGW

RGW

Zone-A

Zone-B

Zone-C

MGR

MGR

MGR

MON

MONMONOSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD

OSD

OSD

VM
RHEL8.2

VM
RHEL8.2

VM
RHEL8.2------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

Cephクラスタ

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.22) rclone(コピーツール)を使い、すべてのオブジェクトデータを現行クラスタから退避用クラスタへコピー

RGW退避用暫定Cephクラスタ

OpenStack課題の対策(2/3)

17

テナントからのAPIリクエスト

3) HAproxyのbackendを暫定クラスタへ変更し、テナントからのAPIリクエストを暫定クラスタに向ける

HAproxy

バージョンアップ期間中
RGW
RGW
サービス切り離し

RGWMONRHEL8.2

MON
RHEL8.2

MON
RHEL8.2

RGW

RGW

RGW

Zone-A

Zone-B

Zone-C

MGR

MGR

MGR

MONMONMONOSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD

OSD

OSD

VM
RHEL8.2

VM
RHEL8.2

VM
RHEL8.2------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

Cephクラスタ

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

4) 切替中に既存クラスタとの差分が発生する可能性があった
ため再度コピー※一時的に古いデータが読む取られる
可能性についてはテナントに説明し了承

RGW退避用暫定Cephクラスタ

OpenStack課題の対策(3/3)

18

テナントからのAPIリクエスト

RGW切離し後、当初想定のStep by Step手順で順次バージョンアップ
すべてのOSDとRGWのバージョンアップが終わったら・・

HAproxy６) HAproxyのbackendを元に戻す

RGW

RGW

RGW

MON
RHEL8.6

MON
RHEL8.6

MON
RHEL8.6

RGW

RGW

RGW

Zone-A

Zone-B

Zone-CMGR

MGR

MGRMONMONMONOSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

OSD

OSD

OSD

VM
RHEL8.2

VM
RHEL8.2

VM
RHEL8.2

5) 退避用クラスタから現行クラスタへ作業期間中の差分デー
タをコピー------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

Cephクラスタ

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

７) 切替中の差分反映のため再コピー

RGW退避用暫定Cephクラスタ

OpenStack次の課題発生

19

ここで次の課題が・・・• これ本当に出来るの？

• 検証環境は2環境しかないが、仕様上、一度バージョンアップすると元のバージョンには戻せない・・• この手順のフィージビリティをどう確認するか• 検証環境でいきなりは試せない・・

課題解決に向けてどうするか・・・？

デジタルツイン環境を構築しよう！

20

課題の対策とある商用環境
MON(MGR/RGW)×3台
OSDx21台

21

OpenStack上にVMで本番環境の疑似環境を構築することで手順検証や障害試験が何度でも可能に
1

商用環境と同じアドレス、ホスト名、構成台数で構築(リソースはスモール)すること
で、構築用playbookは本番用のものを流用

2

Ansibleplaybook

Heat
Template
物理環境相当部分の構築

MONMON
MON
(VM)
(VM)
(VM)

OSD
OSD
(VM)
(VM)

Cephクラスタの設定

OSD
OSD
(VM)
(VM)

Private Network
手順検証がうまくいかなかったら・・・「stack delete」 ⇒ 「stack create + playbook」(1時間ほどで)何度でもバージョンアップ前の現用環境を再構築可能(商用環境と同じアドレスを割り当て)

OpenStackデジタルツイン環境構築にあたって◼ 環境構築で苦労したこと⚫ Heat Template(HOT)はイチから作成• それなりの台数のVMや周辺リソースをまとめて作成するため、効率的な書き方を考える必要があった◼ HOTを作る上で工夫した事⚫ HOTを多段構成で作成• 親HOTから子HOTに差分となる個々の情報(アドレスやホスト名など)を渡す形にして、NWやVMのresourceは1つだけ書く形に集約⚫ 「ResourceGroup」や「for_each」を使って複数ボリュームをまとめて記述• OSDは1ホストあたり10volumeのアタッチが必要だったが、上記の記述によって10個並べて書かずに済んだ

22

デジタルツイン環境構築にあたって

23◼ 作成したHOTの一部サンプル(1/2)
親HOT子HOT・・・
osd_zone_a:
type: ceph_vup_child_az.yaml
properties:
osd_image: {get_param: osd_image}zone: "a"az: "az-1"
int_net_cidr: 10.1.16.160/27
int_net_gw: 10.1.16.190
int_net_dests:- 10.1.16.0/27- 10.1.16.32/27- 10.1.16.160/27
osd_names:- east-ceosd-a-0001p- east-ceosd-a-0002p- east-ceosd-a-0003p
port1_addrs:- 10.1.16.161- 10.1.16.162- 10.1.16.163
・・・

ホスト名、アドレスなど
子HOTに渡すパラメータ

ceph_vup_child_az.yaml

int_subnet:
親から受け取ったパラ
type: OS::Neutron::Subnet
メータによってzoneご
properties:とのNWを作成
name:
str_replace:
template: ceph_int_osd_$zone_subnet
params:"$zone": {get_param: zone}
network_id: {get_resource: int_net}
cidr: {get_param: int_net_cidr}
gateway_ip: {get_param: int_net_gw}
host_routes:
repeat:for_each:<%dest%>: {get_param: int_net_dests}
template:
destination: <%dest%>
nexthop: {get_param: int_net_gw}

ResourceGroupを使ってホスト数分定義
osd_server:
type: OS::Heat::ResourceGroup
properties:
count: 7
次頁に
resource_def:
type: ceph_vup_child_osd.yaml
properties:
osd_image: {get_param: osd_image}flavor_osd: {get_param: flavor_osd}
int_net: {get_resource: int_net}
int_subnet: {get_resource: int_subnet}
az: {get_param: az}zone: {get_param: zone}
osd_name: {get_param: osd_names}
port1_addr: {get_param: port1_addrs}
port2_addr: {get_param: port2_addrs}
osd_index: "%index%"

デジタルツイン環境構築にあたって◼ 作成したHOTの一部サンプル(2/2)
孫HOT ceph_vup_child_osd.yaml# *********************************# *********************************#ceph-osd#volume# *********************************# *********************************
osd_server:
volume:type: OS::Nova::Server
type: OS::Heat::ResourceGroup
properties:
properties:
10volume分をまとめて定義
name: {get_param: [osd_name, {get_param: osd_index}]}count: 10
availability_zone: {get_param: az}
resource_def:
image: {get_param: osd_image}
type: OS::Cinder::Volume
flavor: {get_param: flavor_osd}
properties:
networks:
name:- port: {get_resource: osd_port_1}
str_replace:- port: {get_resource: osd_port_2}
template: ceph_vup_volume_$zone$num_%index%
block_device_mapping_v2:
params:右で定義した
repeat:"$zone": {get_param: zone}
10volumeを1ホスト
permutations: False"$num": {get_param: osd_index}にまとめてアタッチ
for_each:availability_zone: {get_param: az}<%volid%>: {get_attr: [volume, refs]}
size: '20'<%dev%>: {get_param: device_names}
volume_type: 'iops_rw_no_limit'<%bootindex%>:filter:- ['0']- get_attr: [val_grp, value]
template:
volume_id: <%volid%>
device_name: <%dev%>

24

デジタルツイン環境構築にあたって25◼ 良かったこと⚫ 商用環境と同じアドレス、ホスト名、構成台数で仮想インフラ構築したことで、設定用playbookは本番用のものを使いまわし出来てスムーズに構築できた⚫ 仮想化基盤の利用テナントに影響しない環境のため、普段できないような障害パターンの試験やその復旧手順の検証を行うこともできた• 自信をもって作業に望めた◼ 結果として・・・⚫ 作業は無事完了⚫ 作業時の問題発生はゼロ

デジタルツイン環境構築にあたって◼ 育成環境としても良かった⚫ 環境構築や試験をまだチームに参加して日が浅いメンバーに対応してもらう
ことで、Cephのデプロイ方法や障害時の動作についてTry&Errorを繰り返しながら学ぶことができた⚫ 今後新規に入ってくるメンバーに対するハンズオン環境が整い、オンボーディングの効率化ができようになった◼ 結果として・・・⚫ チーム全体のスキルアップにつながった⚫ 少ないメンバーで作業を回す事ができた(当時3人)

2627

作業時間短縮のための工夫

一応作業手順としては確立できたがまだまだ課題が・・・• この作業をストレートにやるとかなり時間かかる• チーム人数が少ないためそんなに時間をかけられない• 他の案件もある、、、

28

課題

29

① 作業期間の長期化⚫ 状況• 当初想定は4ケ月⚫ 問題点• 公式手順では期間を空けずにバージョンアップすることが推奨のため、作業期間中のリスク増⚫ 要因•
データ退避をしながらバージョンアップするため、退避と戻しに時間がかかる② メンバー編成⚫ 状況• 商用作業は2人体制が必須• 当時のチームメンバーは３名• 他案件（新規基盤構築、コンテナ基盤のバージョンアップ等）も並行進捗中⚫ 問題点• 他案件と並行するには作業人員が不足

課題①の工夫点(1)

30

当初の想定
Cephクラスタ①データを退避してクラスタから切り離す(1～2h)
Zone-AMON

MGR MONRGW
RHEL8.2
MON
RHEL8.2MON(RHEL8.2)

OSD(x10)OSD
OSDRHEL8.2
RHEL8.2

Zone-A

Zone-B

Zone-C

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2------------ multi-zone -------------OSD(x10)OSD
RHEL8.2②切り離したノードをバージョンアップする(～1h)
OSD(x10)OSD(x10)OSD
RHEL8.2

OSD
RHEL8.6③バージョンアップしたノードをクラスタに組み込む(1～2h)
Zone-A

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSDOSDRHEL8.2
RHEL8.6

OSD(x10)①～③を台数分繰り返す・・・

OSD
RHEL8.6（作業時間は上記合計ｘOSDホスト台数）

課題①の工夫点(1)31

増設用予備ノードの活用① 予備機をまとめてバージョンアップ(3h)Cephクラスタ
OSD
OSD(x10)
RHEL8.2
OSD
OSD
RHEL8.2
RHEL8.2

MON

MGR MONRGW
RHEL8.2
MON
RHEL8.2MON(RHEL8.2)

Zone-A

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2② Zoneごとに組み込み(1h～5h)

予備機増設

Zone-A

Zone-B

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
OSD
RHEL8.2
RHEL8.6

一括バージョン
アップで時間短縮

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

Zone-C

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

zoneによっては、まとめて組み込みし、時間短縮③ 既存ノードの切り離し
Zone-A------------ multi-zone ------------OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.6

OSD(x10)OSD
OSD
RHEL8.2
RHEL8.2②、③をzoneごとに繰り返す

切離し後、まとめてバージョンアップして、予備機に

課題①の工夫点(2)32

２拠点並行実施⚫ 当初の想定
拠点A⚫ 作業並行化
拠点A

拠点B

n月

n月

n+1月

n+1月

拠点B

n+2月

n+3月

拠点Aのバージョンアップ安定確認期間中に拠点Bのバージョンアップを実施

拠点A

拠点B

課題②の工夫点(1)◼ 現地保守担当者の協力⚫ 人員不足を補うため、他部署に協力を依頼⚫ 作業のシンプル化、手順書の品質を上げることでCephに触れたことのない人でも開発担当とペアで作業可能に⚫ 開発担当１名＋協力者１名体制で当作業を進めることで他案件も並行対応
可能に⚫ 現地担当者のスキルアップの機会にもなってWin-Win33

課題②の工夫点(2)34◼ 作業手順の品質向上⚫ 手順書をMkDocsで作成し、gitで管理することで改版管理、レビューを容易に⚫ コピペ機能を活用し作業ミスを低減
MkDocsで作成した手順書をブラウザで表示して使用

長いコマンドもワンクリックでコピー

35

QA

36