長期的な実験-CROCクラウドへのDell EMC ScaleIOの導入

Dell EMCに基づくScaledIOベースのScaleIOが数年間、確実に、またはそれ以上実行されていた大規模なテストインストールをat笑しました。 彼らは膨大な数の修正を行い、最終的にクラウドインフラストラクチャの製品を完成させました。 Storadzhは、HDDに基づく通常の低速ストレージとオールフラッシュアレイの高速ソリューションとの間の非常に要求の多いニッチを埋めます。 さらに、Software Definedの仕様により、フォールトトレラントストレージをほとんど枝付きのスティックから収集できます。 ハードウェアを節約することはまったく意味がないことを念頭に置いてください。ライセンスのコストが節約のメリットを上回ります。



要するに、本日、ScaleIOを実装し、目を閉じて熊手を歩いた方法を説明します。 100のアーキテクチャー機能とクラウドへの統合について。 そして、もちろん、それは負荷テストについてです。 詳細については、猫へようこそ。

「AWSのように」

前述のように、CROCクラウドには、「標準」と「フラッシュ」の2種類のディスクストレージがあります。 1つ目は、磁気ディスクを備えたアレイに基づいて構築され、ストレージを備えたLUNはクラウドサーバー上に提示され、クラスター化されたファイルシステムに収集されます。 次に、2番目のタイプは、「バイオリンアレイ」として狭い円で知られるオールフラッシュアレイに基づいて構築されます。そのLUNは、ハイパーバイザーを使用してクラウドサーバーに直接提示され、パフォーマンスを最大にするためにVMに直接ルーティングされます。



これらの各ソリューションでは、運用中にさまざまな問題が発生しました。 多数のLUN（より正確には、サーバーへのエクスポート）を持つ「アレイバイオリン」は、APIリクエストへの応答時間を劇的に増加させます。 特に重症の場合、彼らは一般的に生命の兆候を見せなくなります。 LUN自体のプレゼンテーション時間も大幅に増加します。 負荷が増加する磁気ディスクに基づくクラスターFSは、特にスケーリングの試行中に安定性を失います。 プラス数回は鉄を失望させた。



どちらのタイプのストレージも、最小限の抽象レイヤーで、かなり保守的に構築されています。 その結果、従来の「クラウド」ソリューションよりも保守が大幅に難しくなり、さらにスケーラビリティとフォールトトレランスの問題がここに追加されます。 そのため、ソフトウェア定義ストレージ（SDS）ソリューションを新しいタイプのストレージの基盤として検討することが決定されました。これらの問題のほとんどは、アーキテクチャレベルですでに解決されています。



市場で入手可能な多くのSDSソリューションを比較しました。その中には、Dell EMC製品に加えて、Ceph（RBD）、GlusterFS、MooseFS、LizardFSなどの製品がありました。 機能に加えて、私たちにとって重要な要素は、磁気ディスク上のソリューションのパフォーマンスでした。 シーケンシャルIO操作とランダムIO操作の両方で、他の誰よりも先だったのは、このパラメーターのScaleIOです。 同僚のRoman（ RPOkruchin ）は彼の記事ですでにこの製品に基づく興味深いソリューションについて書いています：「 急いで古いサーバーを捨てないで、1時間で高速イーサネットストレージを組み立てる ことができます 」および「 国内サーバーからフォールトトレラントデータストレージシステムを作成する方法 。



今後、パフォーマンステストの結果によると、新しいストレージタイプをAWSの高速な「 スループット最適化HDD（st1） 」タイプとして位置付けることにしましたが、最小ディスクサイズ制限を32 GBに減らし、ブートディスクとして使用できるようにしました。 結果として得られるソリューションの柔軟性のため、新しいタイプのストレージを「ユニバーサル」（st2）と呼び、AWSからの改良バージョンとして位置付けました。

建築

まず、Dell EMC ScaleIOクラスターの構成要素について説明します。

• MDM（Meta Data Manager）-ScaleIOクラスターを管理し、その構成全体を保存します。 残りのScaleIOコンポーネントを管理するためのすべての可能なタスクは、それを通過します。 単一のサーバー、または3つまたは5つのサーバーの管理クラスターで表すことができます。 MDMクラスターのタスクには、システム全体の監視も含まれます。エラーと障害の追跡、クラスターの再構築と再バランス、リモートサーバーへのログの送信、
• Tie Breaker MDM（TB）-クォーラムを投票および維持するためにMDMクラスターで使用され、データを保存しません。
• SDS（​​ScaleIO Data Server）-ScaleIOストレージプール内のローカルサーバーディスクを集約するサービス。 すべてのクライアントIOを受け入れ、レプリケーションおよびその他のデータ操作を実行します。
• SDC（ScaleIO Data Client）は、ScaleIOディスクをブロックデバイスとして表すデバイスドライバーです。 Linuxでは、カーネルモジュールで表されます。
• ゲートウェイ（GW）は、REST API要求を受け入れてMDMにリダイレクトするサービスです。MDMクラスターとのすべてのクラウド通信は、それを介して行われます。 また、これらのサーバーには、クラスターが自動的にインストール/更新/分析を行うWEBコンソールを介したInstallation Manager（IM）もあります。
• また、前述のIMを使用してクラスター全体を管理するには、クラスターのすべてのサーバーにLIA（Light Installation Agent）をインストールする必要があります。これにより、パッケージの自動インストールおよび更新が可能になります。

一般に、各サイトのクラウド内に構築されたScaleIOクラスターは、ほぼ次のように表すことができます。





クラウドには、仮想マシンのディスクに関連するすべての操作の実行を制御するSC（ストレージコントローラー）サービスがあります。 当社が使用するさまざまなストレージシステムでのLUNの作成、必要なハイパーバイザーへのさらなるエクスポート、サイズの増加、削除、およびデバイスのライフサイクルの残りの部分。 このアーキテクチャで最も論理的なソリューションは、これらのサーバーにMDMクラスターを展開することでした。 物理的に、SCおよびMDMは、OSとしてCentOS 7.2を搭載したDell EMC PowerEdge R510サーバー上に存在します。 また、このグループの2つのサーバーにはScaleIOゲートウェイがあり、クラスターを管理するためのREST APIを提供します。 誰もがアクティブ状態ですが、クラウドはアクティブバックアップモードで構成されたバランサーを介してアクセスします。



運用前のテストのために、12個のSDSのプールを準備しました。各4個のSASディスク-Seagate 12Gb / s 10K 1.8Tb 2.5 "。次に、サーバーが地理的に1つのデータセンターにあるため、すべてのSDSが1つの保護ドメインに追加されました。その後、SDSはフォールトセットにグループ化されました。フォールトセットは非常に興味深い概念であり、同時に障害が発生する可能性が高いクラスターにサーバーを分割することを意味します。これは、インストールされたOSの機能と落下する可能性の高いエリアに1つのラック eteoritov。データは1つのリスクグループに陥るのを避けコピーするようなAの方法でミラーリングされます。



フォールトセットを使用する場合は、スペアスペースに合計rawボリュームの一定の割合を割り当てる必要もあります。 これは、最大のフォールトセットに等しい予約スペースで、クラスターの再構築中にディスク/サーバー/フォールトセットが失われた場合に使用されます。 したがって、サーバーラック内のSDSの場所に従ってサーバーをグループにグループ化します。これにより、たとえば、ラックの電源障害が発生した場合など、1つのフォールトセット内のすべてのサーバーが失われた後でも、データのコピーの可用性が保証されます。 ただし、 TIER-III認定を受けたデータセンターでは、この可能性は非常に小さいです。 テストされたプールの合計サイズ：

• 78.5 TBの未加工スペース。
• 25％のスペアスペース-19.6 Tb;
• 29.5 TBの使用可能スペース（複製係数-2を考慮）。

すべてのSDSは、ハイパーバイザー（NC）およびSDC（システムコンバージェンスのバージョン）を備えたノード上にあります。 彼らは、ハイパーバイザーを備えたサーバーにSDSを意識的に配置することにしました。 最初のテストでは、ディスクを使用してサーバーに発生する負荷を監視し、顕著な効果を検出しようとしましたが、CPU、RAM、OSの負荷は無駄でした。 何が嬉しい驚きでしたか。 また、アイドルCPUを備えたディスク専用のサーバーを維持することはあまり有益ではなく、将来的にはSDSの数を増やすことが想定されているため、ソリューションは自然に生まれました。



クライアント（SDC）はそれぞれ、ScaleIOディスクをVMのブロックデバイスとして提供するハイパーバイザーを備えたサーバーです。 物理的に、SDCとSDSは同じCentOS 7.2のDell EMC PowerEdge R720 / R740サーバーにあります。 ネットワークコンポーネントについては、データは56 Gb / s InfiniBand（IPoIB）を介して送信され、制御は1 Gb / sイーサネットです。



クラスター全体を組み立てて、それが機能することを確認したら、テストを進めました。

一次試験と分析

初期のパフォーマンステストは、ハイパーバイザーと仮想マシンの参加なしで実施されました。ボリュームは空のサーバーに接続され、IOPSとMbpsのパフォーマンスの上限を見つけるために容赦なくロードされました。 途中で、さまざまな条件下での最大遅延を決定しました。空のクラスター、障害が発生したなどです。さまざまな結果が得られたため、特に最大負荷の場合、磁気ディスクは最も安定していません。 しかし、私たち自身のクラスターパフォーマンスにはおおよその制限があります.78.5 TBのrawボリュームを備えた48個の1.8 TB SAS 12 Gb / s 10Kドライブのテストクラスターの場合、最も複雑なテストでの最大IOPS値は約8-9千IOPSでした（後に技術があります）テストおよびその他の詳細）。 将来的には、これらの指標にすでに注目しています。



これと並行して、実稼働環境のストレージシステムとScaleIOに転送する予定の仮想ディスクの負荷を分析しました。 2つのサイトから、3か月間の以下の平均を受け取りました。







一方では、書き込みは、操作数の45/55の比率での読み取りよりも頻繁に行われ、他方では、読み取りは大きなブロックで発生し、ストレージシステムに30パーセントまたはさらに70パーセントの負荷をかけます。 実際のサーバーの負荷をできるだけ正確に再現するために、仮想マシンでテストする際に、取得したインジケーターを将来使用しました。

展開がスムーズに進まない

恐怖の安い部屋：暗いどこでも熊手。



クラウドチームの各グループは、新しいタイプのストーリーの導入中に頭痛がしました。 それにもかかわらず、そのようなタスクと困難は常に素晴らしい経験です。 最も重要な問題をリストしようとしました。

ScaleIOのAPIクライアント

「アレイバイオリン」のAPIを使用した興味深い経験があるため、ソリューションを選択する段階で、負荷と並列リクエストの下で各APIの操作性をテストすることにしました。 また、SC（ストレージコントローラー）を含むほとんどのクラウドサービスはPythonで記述されているため、ソリューションに同じ言語のAPIクライアントが含まれていることが重要でした。



そして、ここで問題が発生しました。ScaleIOAPIクライアントはバージョン1.32のみであり、バージョン2.0を既にテストしました。 テストを少し延期し、独自のAPIクライアントpyscaleioを作成する必要がありました 。 基本的なCRUD操作だけでなく、一部のAPIエンティティ、応答の検証、クライアントインスタンスの管理のための本格的なORMも実装することが判明しました。 そして最も重要なことは、すべてのコードが単体テストでカバーされ、機能テストが動作中のScaleIOクラスターで実行できる最も重要なAPI操作のために記述されたことです。



もちろん、APIのいくつかのバグを見つけることができました。 たとえば、ディスクのIO制限を設定（調整）することはできますが、 「iopsLimit（0）は10より大きい数値でなければならない」ため、削除できません。 ただし、SDSレベルでは調整を使用しなかったため、これは重要ではありませんでした。 一般に、負荷のかかったScaleIO APIは優れていることが証明されました。作成された多数のディスクや並列リクエストに問題はありませんでした。

調整

上記の最初の負荷テスト中に、ScaleIOクラスターパフォーマンスのおおよその制限が明らかになり、顧客のディスクを制限する方法と新しいタイプのストレージを配置する方法を決定する必要がありました。 結果を分析した後、IO操作のディスクを500 IOPSに制限し、ディスクのサイズに応じてスループットを制限することにしました。 AWSは、「スループット最適化HDD」ドライブについても同じことを行います。 ディスクサイズが増加すると、制限は自動的に再計算されます。



たとえば、104 GBのディスクの場合（ScaleIOのディスクは8 GBの倍数である必要があります-システムの制限）：

サイズ（GiB）	MBPSベースライン	最大MB / s
104	0.25	26

これらの制限に基づいて、仮想マシン内のディスクは、53 KiBを超えるブロックサイズで書き込みを開始するまで500 IOPSを使用できます。 ディスクサイズが104 GiBの特定の例：

（MBpsスループット/ IOあたりのKB）* 1024 =最大IOPS

26/53 * 1024 = 502 IOPS

15.6 / 32 * 1024 = 500 IOPS

26/64 * 1024 = 416 IOPS

26/128 * 1024 = 208 IOPS



さらにパフォーマンスが必要な場合は、ディスクを増やす必要があります。 また、小さなディスクでより高いパフォーマンスが必要な場合は、IOPSを保証し、それらを変更できるフラッシュストレージのタイプに切り替える必要があります。 幸いなことに、クラウドはストレージタイプ間のディスクのライブマイグレーションを提供し、これにより寿命が大幅に簡素化されます。

シンディスクと空

そして、他のタイプのストレージから実験的なScaleIOへのライブマイグレーションのテスト中に、ディスクが「シック」になり、完全に割り当てられましたが、「シン」に作成されましたが、元のディスクはデータで半分未満でした。



リソースの非効率的な浪費は常に悲しいことなので、私たちはリークの原因を探し始めました。



クラウドはQEMU-KVMをハイパーバイザーとして使用しているため、問題を低レベルで調査できます。 ハイパーバイザーのブロックデバイスドライバーは、BLKDISCARDシステムコールを行い、ディスク内のスペースを割り当てることにより、効率的にゼロをデバイスに書き込むことができます。 ただし、BLKDISCARD操作のサポートに加えて、ブロックデバイスはBLKDISCARDZEROESオプションのサポートも必要です。 そうでない場合、BLKDISCARDが呼び出されたブロックから読み取ると、ゼロ以外が返される場合があります。



ScaleIOディスクはBLKDISCARDZEROESオプションをサポートしていませんでした。 ただし、ScaleIOディスク全体でBLKDISCARDを実行すると、スペースは正しく割り当て解除されます。 ScaleIOでは、BLKDISCARDZEROESのセマンティクスが特別な方法で何らかの方法で実装されているか、フラグが単純に誤って設定されています。 Dell EMCフォーラムで 、彼らはBLKDISCARDZEROESセマンティクスが完全にサポートされていないことを提案しました。ゼロを効果的に書き込むには、BLKDISCARD要求は1MiBの倍数でなければなりません。



問題の解決策が見つかりましたが、ゼロの効果的な記録のこの特定のセマンティクスをハイパーバイザーに「教える」ことが残っていました。 このため、 XEの同様の動作と同様に、QEMU-KVM ブロックデバイスドライバーに変更が加えられました 。 多くの場合、ハイパーバイザーにさまざまな編集を行います。ほとんどの場合、これらは新しいバージョンまたはアップストリームからのバックポートですが、今回はこれらが独自の変更であり、非常に満足しています。 現在、ディスクのライブ移行中に、クラスタースペースが効率的に消費されます。

無効ですか？

更新されたハイパーバイザーを使用したライブマイグレーションの再テスト中に、もう1つの問題に気付きました。移行後のソースディスクとターゲットディスクが異なり、ランダムな場所-最初のブロックで、次に中央でした。 ハイパーバイザーでの最近のドライバー編集、元のディスクイメージの整合性、記録時のページキャッシュの使用を再確認する必要がありました。 問題を特定することは非常に困難でしたが、数時間でなんとかして、すべての無関係な要素を徐々に排除しました。 新しいシンディスクを作成し、ゼロが先頭にあることを確認し、先頭にいくつかのパターンを書き込んでから、BLKDISCARDでディスクの先頭の割り当てを解除し、もう一度試したところ、同じ記録されたパターンが表示されました。



スペースは割り当てられていますが、データは残っていることがわかります。 これはバグに非常に似ているという事実にもかかわらず、結論に急いでドキュメントを読み直さない方が良いです。 また、ScaleIOのストレージプールにはオプション「ゼロパディングポリシー」があり、最初の書き込み時にセクターをゼロで埋めて、非常に大切なゼロを読み取ることができるとしています。 デフォルトでは、このオプションは無効になっており、物理ディスクがプールに追加されていない場合にのみ変更できます。 実稼働環境でのScaleIOのインストールは既にアセンブルされており、準備ができており、積極的にテストされているため、プールを再アセンブルする必要があります。



もちろん、未割り当てブロックへの最初の書き込み操作中にゼロを書き込む追加の操作は、パフォーマンスに影響するはずです。 この効果を評価するために、負荷テストのケースの一部を繰り返し、最初の記録で最大15％の劣化が見られましたが、SDSの負荷は変化しませんでした。



したがって、独自の設計のドライバーは、クラスターの構築における独自のミスを見つけるのに役立ちました。 プールを再構築して必要なオプションを有効にすると、すべてが正常に機能しました。

デバイス名

前述のように、SDSを搭載した各サーバーはハイパーバイザーでもあり、その上に多数のVMがあります。 これは、サーバー上のブロックデバイスの総数が非常に多くなる可能性があり、さらに、仮想マシンを移行したり、ディスクを接続したり切断したりできるため、非常に頻繁に変更される可能性があることを意味します。



これらすべてのディスクの中で、ScaleIO用に提示されたデバイスを強調表示する必要があります。 / dev / sdxなどの短い名前で追加した場合、VMの断続的なデバイスの後にディスクが追加された場合、再起動後にこの名前が変更され、ScaleIOディスクが失われます。 その結果、プールに再度追加する必要があります。これは、各メンテナンス作業の場合にバランスを取り直すことを意味します。 当然、これは私たちにはあまり適していません。



ScaleIOプールを収集し、仮想マシンのない空のサーバーで最初のテストを行いました。 これは、メインプールの増加を計画し始め、SASディスクの新しいバッチを待っているときにのみ考えました。



そのような状況を避ける方法は？ ブロックデバイスへのシンボリックリンクを使用できます。

# udevadm info -q symlink /dev/sdx disk/by-id/scsi-36d4ae5209bf3cc00225e154d1dafd64d disk/by-id/wwn-0x6d4ae5209bf3cc00225e154d1dafd64d disk/by-path/pci-0000:02:00.0-scsi-0:2:2:0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RedHatのドキュメントには、SCSIデバイスを確実に識別するために、システムに依存しない識別子-WWID（World Wide Identifier）を使用する必要があると書かれています。 さらに、これは「配列バイオリン」からブロックデバイスを提示するときにそのような識別子を使用するため、私たちにとってはニュースではありません。 ただし、非RAIDモード（デバイスパススルー、JBOD）では使用できないRAIDコントローラーを介して接続された物理ディスクを使用するため、状況は複雑です。 また、MegaCliを使用して各物理ディスクからRAID-0を収集する必要があります。MegaCliの再構築は、新しいWWIDを持つ新しいSCSIデバイスであるため、使用するのは実用的ではありません。



PCIバス上の物理ディスクを一意に識別するデータを含むシンボリックディスク/バイパスパスリンクを侵害して使用する必要がありました。 ディスクはすでに誤って入力されていたため、オンデューティ管理者は各物理ディスクをScaleIOプールへの新しいパスに追加し、数十時間クラスターの再バランスの進行状況バーをa敬の念を抱かせる必要がありました。

VM内のパフォーマンステスト

ScaleIOディスクはVMのディスクとして使用される予定であったため、開発チームからの大きなリリースを待ち、上記の待望の改善を受け取りました。 また、交換可能なストレージの初期テストと負荷の分析の結果を考慮して、すでに仮想マシン上にあるScaleIOディスクのテストを開始しました。



アルゴリズムは次のように選択されました：CentOS 7.2上の30台の仮想マシン、128 GB ScaleIOディスクが各秒ブロックデバイスに接続され（それぞれ32 Mbpsおよび500 IOPSの制限があります）、1秒ごとにメトリックを削除して監視するための1つのZabbixサーバー別のVMは、4kブロックで連続的に書き込みを続け、そのレコードが500 IOPSを下回るとリソースが不足していることを通知します。 特定の数のテストVMで、同じパラメーターを使用してfioユーティリティでテストを同時に実行し、ScaleIO GUIとテストZabbixを観察します。 Fioの起動オプション：

 fio --fallocate=keep --ioengine=libaio --direct=1 --buffered=0 --iodepth=16 --bs=64k,32k --name=test --rw=randrw --rwmixread=45 --loops=2 --filename=/dev/vdb
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

10個のVMの負荷を持つScaleIO GUIで、実稼働ストレージの平均負荷をほぼ正確にシミュレートします。





Zabbix：







各VMは、約束されたIOPSとMB / sを受け取ります。テストキューの深さが指定されているため、待ち時間は長くなります。 iodepth = 1の場合、レイテンシは約1.6-2ミリ秒です。これは、仮想化レイヤーを考えると、かなり良好です。 ちなみに、IOPS、レイテンシ、およびストレージパフォーマンスについての一般的な記事（IOPS、レイテンシ、およびストレージパフォーマンスの理解）についての良い記事をアドバイスできます。



パフォーマンスの影響と低下をチェックするスタンドアロンVMのグラフでは、テストの全期間にわたって標準からの逸脱はありませんでした。



次に、同時に書き込む仮想マシンの数を徐々に増やし、他のVMのドローダウンがまだ開始されていないときに、約9000 IOPSと800 Mbpsのパフォーマンス制限に達しました。 これらの数値は、VMを使用せずにクラスターをテストしたときに得られた数値とほぼ一致したため、現在のディスクの数と特性については正常であると考えました。



これらのテストの後、クラスターの拡張により生産性がどのように向上するかを理解することにしました。 2つのSDSを撤回し、各ノードを追加して戻すときにパフォーマンスを再測定し始めました。 予備的な結論として、クラスターに新しい各SDSを追加すると、IOPS / Mbpsの上限が直接比例して増加することが確立されました。 したがって、使用可能なボリュームが約5〜6倍になるまで新しいディスクが届くのをすでに待っているので、新しいパフォーマンスインジケータとスマートスロットルを備えた現在の運用ストレージのピーク負荷は怖くありません。



別のテストケースはフォールトトレランスでした。サーバーからドライブを削除し、同じフォールトセット内のサーバー全体をオフにして、他のがらくたを作成しました。 ケーブルをaで切断しない限り。 クラスターに障害は発生せず、データは引き続き利用可能であり、パフォーマンスはほとんど低下しませんでした。1分間のIOPSは10〜15％低下しました。 主なことは、正しい再構築/リバランスポリシーを選択することでした。これは、次のコマンドによって設定されます。

 scli --set_rebalance_policy scli --set_rebuild_policy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SDSに接続されている各ディスクのIO数とMbpsのリビルド/リバランス帯域幅の制限に焦点を当てました。

おわりに

現在、クラスターは、顧客ではなくそれ自体で発生する可能性のある問題やエラーを最大限に把握するために、内部アカウントでパイロットテストを行っています。 Cloud Servicesの作業における最後の小さなエラーを修正した後、すべてのお客様のディスクを作成するための新しいタイプのストレージ-ユニバーサルが利用可能になります。



クラウドへのデモアクセスを取得するか、以下の連絡先で質問することができます。

参照資料

• CROCクラウド
• クラウドチームメール-cloudteam@croc.ru
• 私の個人メールはIEmmanuylov@croc.ruです