KDDIクラウドプラットフォームサービス(以下、KCPS)、ベアメタルサーバーサービス のスクラムマスター岩間解です。 本ブログではZadara Cloud Storage(以下、Zadara)サービスを利用した今までのベアメタルサーバーサービスでは構成できなかった便利な利用方法と実際に構成を組んで検証した結果をご紹介します。ベアメタルサーバーサービス単体では共有ストレージがなく構成に制約がありましたが、Zadaraを共有ストレージとして利用することでベアメタルサーバーサービスを今まで以上にご利用頂きやすくなっていると思いますので、設計の参考にしていただけますと幸いです。

1.   Zadaraを利用した構成の紹介 本章ではベアメタルサーバーサービスとZadaraを活用することで実現できるインフラ構成をご紹介します。

1-1  KCPSベアメタルサーバーサービス単体での課題 本サービスは物理サーバーをそのままご利用頂くサービスになっているため、仮想化環境でご利用いただく際は仮想化ソフトウェアのインストール、仮想化環境の構築が必要となります。さらに、VMware vSphere® High Availability(以下、HA) や VMware vSphere® vMotion® (以下、vMotion)を利用したい場合にはVMware vSAN™(以下、vSAN) 認証取得済みのサーバーを複数台ご利用いただき、共有ストレージの構築、クラスタ構築が必要でした。ベアメタルサーバーサービスにおいて、vSAN認証取得しているのはLargeタイプ及びxLargeタイプといった、比較的スペックの高いサーバーとなってしまうため、比較的小規模な環境を構築される場合にはオーバースペックとなってしまう課題もございました。

1-2  共有ストレージとしてZadaraを利用 ZadaraはベアメタルサーバーサービスからIntrafrontセグメントとBM10G Backセグメント経由で接続し、共有ストレージとしてご利用頂けます。Zadaraを共有ストレージとしてご利用頂くことでvSANを組む必要がなく、SmallサーバーやMediumサーバーでもHA機能の利用が可能となりました。

1-3具体的な利用パターン ベアメタルサーバーとZadaraを利用する構成は以下の通りです。

本構成により、以下2つの利用パターンでご利用頂けるようになります。 ① SmallサーバーやMediumサーバーでも共有ストレージとして利用することで、HA構成を 実現し耐障害性の向上が可能になりました。

② 仮想マシンの可用性に合わせてデータストアの保存先をZadara(共有ストレージ)とローカ ルディスクで使い分けられるようになりました。ベアメタルサーバーにも十分なディス クが搭載されていますので高可用性 が必要な仮想サーバーはZadaraを利用し、低可用性 な仮想サーバーはローカルディスクを選択するという利用が可能となり、リソースを無駄 なくご利用頂けます。運用途中で可用性レベルが変わったサーバーについてはVMware vSphere® Storage vMotion®(以下、Storage vMotion)でローカルストレージからZadaraへ の仮想サーバー移動が可能です。

2. Zadara検証 本章ではパフォーマンス及び測定結果をKDDIが保証するものではございませんが、ベアメタルサーバーサービスでZadaraを利用した検証結果をご紹介します。

2-1 検証構成及び検証内容 “1-3Zadara利用パターン”で記載した検証構成は下記の通りです。 Zadaraへの接続はBM10G Backセグメントを利用し、NFSデータストアとiSCSIデータストアでZadaraを接続し、それぞれを共有ストレージとして利用しています。 検証項目は下記の項目です ① vMotionの実施 ② ホスト障害時のHA動作確認 ③ Storage vMotionの実施 ④ ローカルSSDとNFS,iSCSIでパフォーマンス(iOPS)比較

NFS接続

iSCSI接続

クラスタ設定を行う際にハートビートデータストアに登録する共有データストアが2台以上あることが推奨構成(ディスクの障害かネットワークの障害か切り分けるため)となるため、Zadaraでは2つの論理ボリュームを作成しています。

2-2 検証結果 ① vMotionの実施 ② ホスト障害時のHA動作確認 ③ Storage vMotionの実施 NFS及びiSCSIともに共有ストレージとして設定でき、vMotion, ホスト障害時のHA,Storage vMotionは正常に動作することを確認しました。

④ ローカルSSDとNFS,iSCSIでパフォーマンス(iOPS)比較 本結果を保証するものではありませんが、ベアメタルサーバーのローカルSSD、ZadaraのNFS及びiSCSIでIOPSの値を測定しました。測定条件および測定結果は以下の通りです。ご利用用途に合わせて設計の参考にしてください。

[測定条件] 測定回数：1回 ベアメタルサーバー：i2.Medium-24 Zadara：SSD 3.84TB ２本(RAID1) IOPS測定仮想サーバー：Linux(1CPU,2GBメモリ) 計測ツール：FIO(Version3.7) I/O方式：非同期I/O iodepth=64 テストファイルサイズ：4GB ブロックサイズ4KB 測定コマンド： [シーケンシャル読み込み] fio --ioengine=libaio --direct=1 --gtod_reduce=0 --name=test_simple_read64 --filename=/tmp/test4g --bs=4k --iodepth=64 --size=4G --readwrite=read [ランダム読み込み] fio --ioengine=libaio --direct=1 --gtod_reduce=0 --name=test_random_read64 --filename=/tmp/test4g --bs=4k --iodepth=64 --size=4G --readwrite=randread [測定結果]

2-3 注意事項 ベアメタルサーバーのvSphereからiSCSIのディスクを登録するときの注意点をご説明します。iSCSI登録を行うときは以下の画面で設定を行いますが、赤枠の“ネットワークポートのバインド”設定は不要です。iSCSIで接続するアップリンクは一つの物理ポートにすることが推奨されていますが、ベアメタルサーバーのNICは二つの物理ポートでチーミング設定を行うことを前提としておりますので、Active/Standby構成にする必要があります。iSCSI接続ではLACPはサポートされておりませんのでご注意ください。

以下の警告がでますが、対向スイッチのポートをshutdownしたときにアップリンクが正常に切り替わる(iSCSIが切断されない)ことを確認しました。

3 最後に 本ブログではKCPSベアメタルサーバーサービスでZadaraを利用した新しい構成を紹介させて頂きました。我々のチームはこれからもより便利な方法を検討及び検証を行い本ブログで紹介させていただきますのでご期待ください。