小売ネットワークのデータストレージを集中管理し、段階的に最適化した方法

Riverbedソリューションを使用して、数百の大規模な銀行支店の金庫を中央データセンターに転送することについて話し合った後、システムの有効性をチェックするために、製品の「百プラス」コンポーネントを技術的に掘り下げ、同時にデータ統合のオプションを検討することを決定しましたSteelFusion CoreおよびEdgeのほか、エンジニアリングの取り組みと顧客のメリットを評価します。



私たちの経験では、小売業者の典型的な地域支店は、ネットワークスイッチのペア、サーバーのペア、テープライブラリ、およびカセットを交換する清掃員で構築されています。 ライブラリが外部ドライブを好む場合があります。 カセットは単純に保管することも、定期的にエクスポートすることもできます。 外付けドライブでも同じです。 WANチャネルの幅はMbpsのペアに制限され、高い値に達することはめったにありません。



小売業者のセントラルオフィスのインフラストラクチャはもう少し複雑です。多数のサーバー、ミッドレンジのストレージシステム、バックアップサイトもあります。 したがって、一般的に、小売業者の地域支店のデータを統合するという考えは、このような場合に適用できます。 私たちは数時間で私たちの店でテストベンチを組み立てました。 ここで何が起こったのですか。







架空のセントラルオフィス（DPC）の研究所の1つを利用し、vCenterを展開して、単純なHAクラスターを組み立てました...



アフィリエイトとして機能するラボでは、唯一のEdgeハードウェアをインストールしました。 狭いチャネルはWANemエミュレーターによってシミュレートされ、20ミリ秒の遅延で2048–3072 kbit / sの帯域幅の特性を取得しました。 テストでのパケット損失はシミュレートされませんでした。



サイト間のデータブロックは、オプティマイザーによるiSCSIトラフィックストリームの圧縮および重複排除後に移動を実行します。 理解を深めるための簡略図を以下に示します。







SteelFusion Core Gateway（SFC）は、ディスクスペースをブランチに投影するために使用されます。 仮想マシンとしてデータセンターにインストールしました。 データセンターのトラフィックを最適化するために、仮想SteelHead VCXも使用しました。この仮想化では、対応するトラフィックインターセプトルールを設定し、オプティマイザーを介してリダイレクトします。



鉄の枝部分は、独自の方法で設計されています。 エッジサーバー（この例では3100）は2つのノードに分割されています。

•Riverbedサービス（トラフィック最適化、ブロックストア管理、ハイパーバイザーなど）の運用を担当するRiOSノード。

•ネットワーク部分で事前構成されたESXiハイパーバイザーを備えたノード。







サーバー内のディスクはブロックストアエッジキャッシュです。 RiOSノードによってのみ制御され、ESXiのキャッシュに同じ月スペースが割り当てられます。 同時に、ブロックストアへのESXiノードのアクセス（実際には、同じアイアンボックス内のディスクへのアクセス）は、内部インターコネクトを介してiSCSIプロトコルを使用して1 Gbpsの速度で実行されます。



この構成では、RAID10に4つの2TB SATA 7.2Kディスクがあり、RAID10にも4つのSSD 240 GBディスクがありました。 ホットスペアディスクはありませんが、CLIから強制的に障害ディスクをグループに入れることができます。 これは、複数のドライブに障害が発生した場合にデータを回復する必要がある場合に便利です。 合計で、ブロックストアの下で3 TBを少し超える容量が利用可能です。



すべてが正しく行われていれば、ルーティングの構成とRdiskトラフィックの最適化を間違えることは困難です。 従うべき明確なスキームがあります。 それ以外の場合、クレイジーなシステムへのボーナスとして、直接Edge-Coreバンドルの絶え間ない中断、不安定なRiOS接続、および機嫌が悪くなります。これは、最初にEdgeから間違ったVCXオプティマイザーインターフェイスにトラフィックを切り替えることで得られました。



Zenがついに買収されたとき、典型的なEdgeストレージ操作のテストに取り掛かりました。 混合負荷の下で、SSDディスクのキャッシュを考慮して、許容可能な応答時間で、相互接続速度に対応するパフォーマンスを得ました。











次に、Exchangeを備えた仮想マシンでEdgeを完全にロードし、LoadGenを使用して約500人のアクティブな作業を模倣することにしました。 同時に、VMオペレーティングシステムはvmdkドライブにインストールされ、Exchange自体は150 GB RDMにインストールされました。



SFEDがこのような負荷向けに設計されていないことは明らかですが、地獄は冗談ではありません...さらに、システムが正しく動作し、安定することを確認するために、Core-Edgeバンドルのブレークで遊ぶことにしました。

興味深いことに気づいた

最適化を実行し、送信データの量を90％に減らすと、ブロックストアキャッシュが非常に速くいっぱいになり、複製する時間がないだけでなく、システムがハングアップしました。 SFEDがブロックストアの3 TBのスペースをうらやましいほどに飲み込んだとき、ホストは書き込みエラーを受け取り始めました。







判明したように、トラフィックの最適化の作業を示すという点では、構成は正しくありませんでした。 その理由は次のとおりです。

• RDMディスクはブロックストアにキャッシュされますが、レプリケーション中にストリームは重複排除されません。 最適化は、VMFSストレージとその内部でVMDKディスクを使用する場合にのみ機能します。 したがって、Exchangeでのボリューム複製は非常に遅くなります。
• 仮想マシンでの交換作業は、データストア内のOSシステムディスク上にあるスワップファイルに積極的に関与していました。 したがって、最適化の対象となったのは彼と彼の動的な変更でした。 したがって、チャート上のデータ量の大幅な削減と急いでいます。
• キャッシュの不均衡な充填は、システムに使用されるディスクのタイプに関係しています。シック、レイジーゼロ。

そして、この瞬間からより詳細に。



VMDKディスクのさまざまなタイプのフォーマットは、ブロックストアで異なる方法でキャッシュされます。



例：20 GBを使用した100 GB VMDK

VMDKタイプ	WANトラフィックの使用	アレイの太い枝で使用されるスペース	アレイの細いluで使用されるスペース	VMDKフラグメンテーション
薄い	20 GB	20 GB	20 GB	高い
厚い熱心なゼロ	100 GB + 20 GB = 120 GB	100 GB	100 GB	なし（フラット）
厚い遅延ゼロ（デフォルト）	20 GB + 20 GB = 40 GB	100 GB	20 GB	なし（フラット）

そのため、シンボリュームを使用する場合、ブロックストアが最も効率的に利用されます。 Lazy Zeroedディスクを使用すると、最初の記録中にVMFS Datastoreブロックがゼロ化されるため、キャッシュおよびレプリケートされたデータの数が2倍に増加します。 ボリューム全体のゼロブロックと記録データのブロックがキャッシュされるため、最も「食いしん坊」なのはEager Zeroedメソッドです。 さまざまなタイプのディスクのキャッシングをさらにテストした結果、期待どおりの結果が得られました-キャッシュは必要なだけ正確に満たされました。



次のステップは、新しいインフラストラクチャを展開するときにシステムを使用する効果を確認することでした。 実験の純度のためにブロックストアキャッシュをゼロにし、データセンターに仮想マシンを備えたVMFSストレージを準備し、設定しました。

仮想マシンOS	Ubuntu	Ubuntu
仮想マシンのストレージ	コアを介したデータセンター	データセンター
VMディスク容量	16 GB	16 GB
ブートデータボリューム	〜370 MB
WANチャネル幅	100 Mbps

完成した仮想マシンを初めてロードするときには、ワイドチャネルでの作業はそれほど効果的ではありません。 しかし、送信される有用なブロックが少なくなり、ブロックストアキャッシュの読み取りヒットがますます増えているため、VM自体の作業は非常に高速です。







最適化の利点は、実質的にチャネルがない場合に明らかです。







もちろん、EdgeにVMをインストールしたときに、予測されたデータストアにブートイメージを配置して、ブロックストアへのフラッシュが事前に行われないようにしました。



VMのインストールプロセスと送信データの最適化の結果：







読み取りヒットおよび読み取りミスのブロックストア統計：







TCP接続最適化統計：







WANおよびLANチャネルの輻輳：







ここでは、WANチャネルが実際にどの程度使用されているか、およびトラフィックの最適化によってどのような実際のデータ転送速度が保証されているかを確認します。



1時間後、新しくインストールされたVMは完全にデータセンターに残されました。 グラフでは、複製されたデータの量がどのように減少するかがわかります。







主な疑問が残っていました。この全体をバックアップする方法、できれば自動化の度合いを高める方法はどうでしょうか。 回答：Edge-Coreのスナップショットの組み込み機能を使用します。



スナップショットには2つのタイプがあります-アプリケーション整合性（アプリケーションはディスクにデータバッファーを書き込み、その後ボリュームのスナップショットが取得されます）とクラッシュ整合性（バッファーからデータが書き込まれていないボリュームのスナップショットは、異常終了後にアプリケーションを起動することと同等です）

Application Consistentスナップショットは、VMDKを使用する場合はVMWare Toolsを介して、NTFSを使用する場合はVSSを介して仮想マシンで動作します。



この機能は、ESXiおよびIBM Storwize V7000ストレージと組み合わせてテストしました。



仕組み：







メカニズム：

1. スケジュールに従って、EdgeはコマンドをESXiホストに送信して、Application Consistentスナップショットを作成します。
2. コマンドを受信すると、ESXiホストはコマンドをゲストVMに送信し、VMware Toolsを介してバッファーからデータを書き込みます。
3. フラッシュバッファプロセスが完了すると、Edgeはデータセンターに複製されたデータのストリームに特別なトークンを配置します（コミット文字列）。
4. Edgeは以前のESXiホストに接続し、以前に撮影したスナップショットを削除します。
5. WANチャネル内のマーカーは、マーカーがディスクアレイ上の衛星に書き込まれる前のすべてのデータであるコアに到達します。
6. マーカーにデータを書き込んだ後、コアはムーンスナップショットを初期化するコマンドでディスクアレイにアクセスします。
7. ディスクアレイがスナップショットを作成した後、CoreはESXi上のProxy-Backupサーバーに接続し、過去のVMの登録を解除し、データストアを無効にします。
8. 次に、Coreはディスクアレイに再接続し、スナップショットクローンを作成して、アレイからプロキシサーバーに提示します。
9. その後、Coreはプロキシサーバーにスナップショットをマウントして仮想マシンをインポートするよう指示します。

それだけです。 仮想マシンは、vSphere互換ソフトウェアを使用してバックアップできます。 Netbackupを使用して、テストマシンを正常にバックアップしました。







最終的に、サーバーで別々のサーバーとローカルドライブを使用することは安価で高速ですが、長期的なデータストレージと多くのオーバーヘッドに疑問が生じます。 同時に、バックアップはもちろん、ブランチ内のテープ上でも、たとえば独自の重複排除およびトラフィック圧縮メカニズムを備えたCommVaultなどのさまざまなソフトウェアを使用しても実行できます。



SteelFusionを使用したデータセンターのデータ統合の場合、最初に地域データとそのバックアップを保存するための適切な量のリソースが必要です。 ブランチの計画負荷に応じて、ソケットの数に対してデータセンターのプロキシバックアップサーバーのライセンスを取得すると、バックアップをさらに節約できます。



ブランチの古典的なレイアウトとキーポジションの概算コストを考慮すると、次の図が得られます。

クラシックレイアウト（ブランチ）	推定費用、$
2 xサーバー（1 CPU、32GB RAM、5×600GB HDD）	20,000
テープライブラリ（1ドライブ）	10,000
延長サポート（24/7/7時間）、1年	7,000
VMware vSphere標準：2ソケットライセンス	4,000
2ソケットのサブスクリプション、1年間	1,500
バックアップ：2ソケットのライセンス	2,000
サポート、1年	5,000
設備投資 （1年目）	49,500
OPEX （その後4年間）	54,000
TCO（5年）	103 500
30 支店の TCO （5年間）	3 105 000

ブランチでSteelFusion構成を使用すると、以下が得られます。

SteelFusionレイアウト（ブランチ）	推定費用、$
装備品
2 x SteelFusion Edge 2100	31,000
ハードウェアおよびソフトウェアのサポート：
SteelFusion Edge Appliance 2100ゴールドサポート、1年間	9 500
ソフトウェアライセンス：
VSP、BlockStream、WAN Opt（1500接続、20 Mbps）	7 800
設備投資（1年目）	48,300
OPEX（その後4年間）	38,000
TCO（5年）	86 300
TCO（30支店、5年）	2 589 000

データセンターには、2台の仮想マシンSteeFusion Coreと2台のIron Steelheadを配置しました。

SteelFusionレイアウト（DPC）	推定費用、$
装備品
2 x SteelFusion Core VGC-1500	46,800
2 x SteelHead CX 770	30,400
ハードウェアサポート、1年：
SteelFusion Core Virtual Appliance 1500 Goldサポート、1年	9,400
SteelHead CX Appliance 770ゴールドサポート、1年間	5,400
ソフトウェアライセンス：
ライセンスSteelHead CX 770-H、 30Mbps、2500 conn	21,600
設備投資（1年目）	113,600
OPEX（その後4年間）	59,200.00
TCO（DPC、5年）	172,800

5年にわたるTCOを考慮すると、SteelFusionを使用すると、少なくとも300,000ドルの節約になります。 そして、これはクラシックバージョンの追加オーバーヘッドなしです。 また、ブロック複製ストリームだけでなく、さまざまなアプリケーションプロトコルも圧縮できる可能性があるため、通信チャネルのコストをさらに削減できます。

参照資料

• 銀行内の速度を損なうことなく、数百の支店をセンターに転送することに言及
• トラフィックの最適化に関するLikbez
• ネットワーク探偵の例
• ひどい風邪の鉱床の履歴チャネルの最適化
• 分散およびストレージに関する脳吹き教育プログラム
• リラックスするユニットの物語
• さて、私のメールはSmesilov@croc.ruです