HPESynergy上のハイパーコンバージドRosplatformと3PARストレージシステムの統合

どういうわけか、Rosplatform（R-VirtualizationおよびR-Storage）をハードウェアストレージシステム（3PAR）と統合する必要があり、これはさまざまなシナリオで非常に役立ちます。

 

シナジー構成

以前は、この種の統合は、Huaweiセンターブレードのブレード（ブレードCH121 v5）とDorado 5000 v3ストレージシステムでテストされていました。ストレージシステムの上にあるRosplatformaのP-StorageのSDS（ソフトウェア定義ストレージ）は、すべてのフラッシュのために非常によく表示されましたが、利用可能な場合はSynergyを使用しましたD3940モジュールのJBODディスクは、すべてがはるかに興味深く、柔軟性があります。



3つのサーバーブレード（Synergy 480 Gen10（871940-B21））：

• それぞれに2つのIntel®Xeon®Platinum8270CPUがあります。
• 20 Gb / sの2つのポートをネットワーク化します。
• RAM256GB。
• ブレードにはハードドライブはありません。
• Synergy 2HDDディスクモジュールでは、OS /ハイパーバイザーごとにRAID1で900GB、メタデータ+キャッシュロール用に3SSD HPE VK0960GFDKK 960GB（それぞれ1つのサーバー用）、および900GB用に9HDDEG0900JFCKB。

OSは、SynergyディスクモジュールからRAIDコントローラーを介してチャネルを介してロードされました。

SynergyディスクモジュールからJBODチャネルを介して展開されたローカルSDS。

3PAR構成

Synergyは3PAR（FC16 Gb / s）に接続されています：

200GBの容量を持つSSDからの1つのLUN（1対多）RAID6。HDDからの9つのLUNRAID6、それぞれ150GBの容量（ブレードごとに3つのLUN）。





図：1テストスタンドの図。

シナリオの説明

3PARと統合するためのいくつかのオプションをテストしました。これらは、混合構成で一度に同時に使用することもできます。



3PARからそれぞれ150GBの個別のLUNにRosplatformをSDSで展開するシナリオ：





図。2

3つのノードごとにストレージシステムを備えた個別のLUNにRosplatformをSDSで展開するシナリオでは、150GBのLUNが3つあるFCが提示されました。



ストレージシステムでは、HDDディスクからRAID6で構成されていました。図では。図2は、10Gbとスイッチを概略的に示していますが、実装は20Gbポートを備えたSynergyスイッチのレベルで行われ、一方のインターフェイスは管理と仮想化用で、もう一方はSDSストレージ用です。



このシナリオは、次のオプションが機能することを確認するためにテストされました。

• SDSRosplatformは3PAR上で動作します。
• ローカルSSDキャッシュを追加することにより、3PARを介したRosplatformaのSDSを強化します。
• VM構成ファイルを格納するための小さなSDSRosplatformを作成することにより、VM自体がLUN3PAR上に作成されます。
• 3PAR上でSDSRosplatformaをテストし、ローカルディスクのダッシュよりもわずかに遅いダッシュ用に定義します。

2）3PARからLUN上にVMを作成するシナリオ：





図。33PARからLUN上にVMを作成するシナリオ。



SSD forVMのLUN200GBRAID6がストレージとともに提示されました。LUN構成は1対多です。

このシナリオは、機能を検証するためにテストされました。

• 3PARからVMLUNに直接接続します。
• qcow2を使用せずに、接続されたVMLUNをプライマリディスクとして使用します。
• ゲストクラスターファイルシステムの後続のインストールのために、同じ200GBLUNが接続された複数のVMを使用します。
• 3PARから200GBのLUNを使用してVMを移行すると、残りのノードでこのVMを再起動するとノードがクラッシュします。
• 3PARからのSDSをVM構成ファイルのストレージとして使用し、ゲストOSを3PARからLUNに直接展開します。
• Synergyモジュールのローカルディスク上のSDSをVM構成ファイルのストレージとして使用し、ゲストOSを3PARからLUN200GBに直接展開します。

設定の説明

各ノードのすべてのシナリオで、クラスターの通常の展開の前に、Rosplatformイメージから3つのノードをインストールした直後に実行された同じ設定が以前に行われました。クラスター自体をインストールおよび構成するための簡単な手順は、前の記事に記載されています。



1.マルチパスサービスの自動ロードを有効にする：

#chkconfig multipathd on

2.モジュールのロードを有効にする：

#modprobe dm-multipath
#modprobe dm-round-robin

3.構成テンプレートを作業構成のフォルダーにコピーします。

#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/

4.次のパラメータの下の包含パターンをチェックインします。

defaults {
        user_friendly_names yes
        find_multipaths yes
}

5.VMの共有ディスクのエイリアスを追加します。

multipaths {
        multipath {
#               wwid                    3600508b4000156d700012000000b0000
#               alias                   yellow
#               path_grouping_policy    multibus
#               path_selector           "round-robin 0"
#               failback                manual
#               rr_weight               priorities
#               no_path_retry           5
#       }
        multipath {
                wwid                    360002ac0000000000000000f000049f4
                alias                   test3par
        }
}

6.サービス開始を確認します。

#systemctl start multipathd

7.サービスを確認し、mpathを使用してデバイスを表示します。

#multipath –ll

8.必須の再起動：

#reboot

9.サービスを確認し、mpathを使用してデバイスを表示します。

#multipath –ll

次に、標準のクラスター設定が実行されました。





図：マルチパスサービスを有効にする前の4つのWebUI。





図：5マルチパスサービスを有効にした後、dmデバイスが表示されました。



Rosplatformaクラスターを作成した後のスクリーンショット。VM用の200GBLUNは、特別に割り当てられていない役割を持ってい





ます。6Rosplatformaクラスターを作成した後のスクリーンショット。



スクリーンショットは、2つのtier0とtier1を示しています。ここで、tier0はローカルSDSであり、tier1はSDS over3PARです





。7ローカルSDSおよび3PAR以上。



次に、VMは、代わりに3PARからの200GBLUNが接続されたローカルディスクなしで作成されました。

#prlctl set testVM --device-add hdd --device /dev/mapper/ test3par

VMは、次のパラメーターを使用して作成されました。

• タイプ-CentOSLinux
• vCPU-4
• RAM-8
• ゲストOS-Centos7（1908）

移行テスト

移行テストは、ゲストツールがインストールされているかどうかに関係なく実行されました。

いずれの場合も、VMは停止せずに正常に移行されました。





図： 8VM移行の結果と時間。



Test1-ローカルディスクイメージQCOW264GBと3PARからの200GBLUNを備えたtest10VMのライブマイグレーションのみを使用した同じパラメーターを持つ通常のVM。



プロセス中に別のノード上のVMディスクイメージのコピーに切り替えるステップがなく、クラスターの任意のノードから見えるLUN 200GBへのリンクを使用して構成ファイルのみがコピーされるため、移行時間は短くなります。





図： 9Pingの結果。



ライブマイグレーション中に、3PARから200GBのLUNを使用してVMにpingが実行されました。



1つのパケットのみの損失が記録され、SDS上の通常のVMでもまったく同じことが起こりますが、VMはネットワーク経由で引き続き使用可能であり、引き続き機能します。

緊急シャットダウンテスト

サーバーの電源がオフになり、3PARから200GBのLUNを備えたVMがあり、HAサービスが欠落したノードを検出した後、テスト対象のVMは、デフォルトのdrsアルゴリズムに従って選択された別のノードで正常に再起動しました。 ping中に、7つのパケットが失われました。切り替え時には、VM構成ファイルのみが起動され、ゲストOSには常にLUNへの接続パスを介してアクセスできました。



また、VM構成ファイルが正常にバックアップされ、このVMコピーから復元すると、正常に開始されるバックアップの作成もテストしました。







3PARからの200GBLUNを使用したVMへの順次書き込みのテスト。これは、Rosplatformaが中間層ではなかった3PARからのこのLUNのパフォーマンスを示し、テストはゲストOSおよび3PARストレージシステムの動作を示しています。



3PARからの200GBLUNを備えたVM内で使用されるfioパラメーター：

[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/

ゲストOS内のクラスター化されたファイルシステムでテスト

図：10ゲストOS内のクラスター化されたファイルシステム。



1つの200GBLUNが2つのVMに接続されているシナリオは正常にテストされており、GFS2クラスターファイルシステムがゲストOSを使用してVM内にインストールされています。テスト中、VMまたはホストの1つがオフになり、その後、他のVMがこのLUNで動作し続け、そこからファイルの書き込み/読み取りを行いました。以下は、VM内のGFS2設定のスクリーンショットであり、ペースメーカーコマンドの出力も示されています







。LUN上部のRosplatformaのさらなるSDS：





図。11 3PARLUNにデプロイされたSDSRosplatformを使用した構成。



同じシナリオが、ゲストOSを使用してVM内にクラスターファイルシステムがインストールされた1つのLUN 200GBから2つのVMで正常にテストされましたが、3PARからのLUN上に作成されたSDSRosplatformaからのデータストアがVMの場所として使用されました。テスト中、VMまたはホストの1つがオフになり、その後、他のVMがこのLUNで動作し続け、そこからファイルの書き込み/読み取りを行いました。





図： 12Synergyディスクモジュールからのキャッシュの役割についてSSDを追加してテストします。



同じシナリオが、2つのVMに接続された1つの200GB LUNで正常にテストされ、クラスターファイルシステムがゲストOSを使用してVM内にインストールされましたが、3PARのLUN上に作成されたSDSRosplatformaのデータストアがVMの場所として使用されました。さらに、このデータストアは、SynergyディスクモジュールからキャッシュとしてSSDを追加することにより、パフォーマンスが向上しています。テスト中、VMまたはホストの1つがオフになり、その後、他のVMがこのLUNで動作し続け、そこからファイルの書き込み/読み取りを行いました。

Rosplatformノードでのクラスターファイルシステムテスト

図： 13 3PAR LUN200GBのSDSRosplatformaにあるVM構成ファイルを使用したテストが提示されました。



Rosplatformaノードにインストールされたクラスターファイルシステム上のVMディスクイメージ用の3PARからの共有ストレージを使用してシナリオをテストし、これらのVMの構成ファイルをRosplatformaのSDSに配置しました。テスト中、ホストの1つがオフになり、その後、VM構成ファイル用のSDSクラスター上のレプリカ3およびVMディスクイメージ用のクラスターファイルシステムの3つのログに従って、他の2つのホストが動作したため、VMはディスクイメージでの作業を続行する必要がありました。





図： 14SDSは3PARからLUNに持ち込まれます。



シナリオは、Rosplatformaノードにインストールされたクラスターファイルシステム上のVMディスクイメージ用の3PARからの共有ストレージでテストされ、これらのVMの構成ファイルはRosplatformaのSDSにあり、SDSは3PARからLUNに発生しました。テスト中、ホストの1つがオフになり、その後、VM構成ファイル用のSDSクラスター上のレプリカ3およびVMディスクイメージ用のクラスターファイルシステムの3つのログに従って、他の2つのホストが動作したため、VMはディスクイメージでの作業を続行する必要がありました。





図： 3PARからのLUN上の15SDS tier0、Synergyモジュールからのディスク上のSDStier1。



シナリオは、Rosplatformaノードにインストールされたクラスターファイルシステム上のVMディスクイメージ用の3PARからの共有ストレージでテストされ、これらのVMの構成ファイルはRosplatformのSDSに配置され、SDS tier0は3PARからのLUNで発生し、2番目のSDStier1はモジュールからのディスクで発生しました。シナジー。テスト中、ホストの1つがオフになり、その後、VM構成ファイル用のSDSクラスター上のレプリカ3およびVMディスクイメージ用のクラスターファイルシステムの3つのログに従って、他の2つのホストが動作するため、VMはディスクイメージを処理する必要がありました。しかし、GFS2でのkvm-qemuの動作に問題がありました。長い調査の後、GFS2のロックマネージャーが失敗し、Rosplatformaはこのためにクラスターの別のホストでVMを起動できません。質問は未解決のままです。図13および14のオプションと同じです。このシナリオで考えられる問題は、qcow2とrawイメージを操作するkvm-qemuの特性にあります。この場合、書き込み操作は同期して発生し、GFS2のロックマネージャーはそのような操作に制限されます。

結論

SDSから3PARからのLUNおよび3PARからのLUNプレゼンテーションまでのオプションは非常に機能しており、インフラストラクチャでの作業に使用できますが、もちろんいくつかの欠点があります。



たとえば、月面のSDSの場合、パフォーマンスは常にローカルディスクのSDSよりもわずかに低くなります。これは、キャッシュの役割を持つローカルSSDによって改善できますが、通常のSDSは常に主に高速になります。オプションとして、ストレージシステムのSDSを別のシューティングギャラリーで構成できます。もう1つの重要でないマイナスは、フォールトトレランスです。SDSでは、各ノードはコントローラーであり、少なくともクラスターは3つのノードで始まり、ストレージシステムの場合、ラックごとに常に2つのコントローラーがあります。 SDSの場合、これは単一の障害ポイントですが、これらの欠点にもかかわらず、このようなシナリオは、外部ストレージからSDSへの段階的な移行中、または既存のストレージシステムの廃棄時に発生します。さらに、重複排除、圧縮などのストレージシステム自体の機能があります。これは、アーキテクチャアプローチの特殊性のためです。SDS Rosplatformaにはありませんが、3PARにはそれがあり、上記のシナリオのおかげで、ストレージレベルで使用できます。



独自のクラスターシステムを備えたゲストシステムのVMのLUNプレゼンテーションのシナリオも関連しています。各VMに個別にLUNを提示する場合、多数のVMのライフサイクル中に自動化が行われないなどの欠点が発生します。これは、Rosplatformノード上のクラスターファイルシステムが原因である可能性がありますが、この場合のkvm-qemuを使用したGFS2は失敗しました。他のファイルに使用すると、Rosplatformでの緊急テストでもすべてが機能しますが、VMイメージがそこに配置されるとすぐに、GFS2ロックマネージャーは緊急テストで失敗します。おそらく、この問題は解決されるでしょう。



マルチパスを使用するための上記のシナリオは、テープライブラリをリンクする場合に役立ちます。Rosplatformには、Pストレージクラスターフォルダーまたはローカルフォルダーにコピーを書き込むことができる組み込みのバックアップシステム（SRK）がありますが、スクリプトを自分で作成するまでテープデバイスを操作することはできません。または、これらの目的で、rubackupなどの外部SRKを使用できます。テープでの作業に加えて、LUNが接続されたVMのコピーを作成するのに役立ちます。これは、ストレージシステムと統合するときに重要です。