良い一日
たまたま、私は過去5年間ストレージシステムに携わってきましたが、そのうち4年間はEMC社の中間レベルのシステムに専念しました。 おそらくEMCについては別の投稿に専念しますが、これは昨年、かなり複雑な構成で対処されたNetAppストレージシステムに専念します。 特別な技術的詳細や美しい写真なしで、買い手、ユーザー、管理者の側から見ます。
誰が気にします-猫へようこそ。
それがすべて始まった方法
それはすべて、2番目のリモートデータセンターの構築を決定したという事実から始まりました。 古いストレージシステムのリソースが使い果たされており、いずれにしてもデータセンターをゼロから構築する必要があるため、約1000の仮想マシンと約20のOracle製品データベース+多くの開発の負荷に耐えられるものを購入することにしました。 それに応じて、リモートデータセンターは、データセンター全体のレベルでのレプリケーションとフォールトトレランスを意味します。 私は選択のすべての側面にこだわるつもりはありませんが、応募者は日立、EMC、NetAppであったと言います。 NetAppを選んだのは、 テスト後、NFS上でOracleがどのように動作するか、クラスとしてFC SANがないことを気に入ったので、既存の10gbネットワークを使用できます。 その上で停止しました。
タスクは何でしたか
- アクティブ-アクティブモードのリモートサイト（ベースの一部の意味で、一部はRACでなく、一部）
- パーティーの1つが崩壊した場合のOracleデータ損失-0秒
- データベースを反対側に切り替える時間-クラスターソフトウェアを使用して最大5分（Veritas）
- VMware仮想マシンの継続的な可用性
最終的に何が起こったのか
そして、データベース用の2つのサイト、SnapMirrorレプリケーション+仮想マシン用のMetroCluster （SyncMirror）構成の1つのFAS3270システムで、2つのFAS6280システム、それぞれ2つのコントローラーが判明しました。 Ontapバージョンは、すべてのシステムで8.1.2です。 どこでも-FlexVolとRaidDP 。
すぐに言います-FAS3270メトロクラスターに問題はありません。 絶対に。 絶対に。 動作し、割り当てられたタスクを正確に実行し、サイト間で半分に分割された約1000台の仮想マシンをプルします。 問題や落とし穴はありません。 コントローラが再起動すると、仮想マシンはI / Oで15秒間フリーズし、何も起こらなかったように動作し続けます。 コントローラーが戻るときの逆切り替えには、ほぼ同じ時間がかかります。 このシステムでは、すべての200％に満足しています。 しかし、正直なところ、その上でのロードはまだ約50％であり、ディスクI / Oで約25-30％です（75アクティブディスク/サイドで約4500ディスクiops）。 練習が示すように、これは彼が問題なく働くことを可能にするものです。
NetAppとともに、FAS6280の仕様が作成され、サイジングが実行され、問題が発生した場合に発生する可能性のあるすべての落とし穴について議論しました。 私たちが議論したように、すべてがうまくいくと確信していました。 そして、次の図について説明しました。
- 各データベースには、データ+インデックス、アーカイブログ、やり直し+元に戻すの3つのセクションが含まれています。
- 4つのコントローラーに分割された20のデータベース、コントローラーのペア間のレプリケーション。
- 2つのセクション、データ+アーチ-非同期スナップミラー、1分に1回。 REDOセクションは同期スナップミラーです。
- 開発は、4つのコントローラーすべてで薄い層で塗りつぶされます。
起動時には、現場での廃棄は各コントローラーで約40％で、ディスク水出力による使用率は20％でした。 ここから、システムがただいじり回っていたと結論付けることができます。
現在、オンサイトリサイクルは約85％、ディスクでは平均約70％、ピーク時は90％です。 数が100％の場合、これはコントローラーあたり32,500のディスク操作です。 ディスク操作！= nfsのiopsの数。
問題1-同期SnapMirror
約束-コントローラーへの同期レプリケーションの30セッション。 それだけです 示されていること以外の詳細はありません-同期レプリケーションは待ち時間ネットワークに非常に敏感です。 荷重方向に関する詳細はありません。
実際、 異なる方向に向けられた 2つのセッションでも、同期レプリケーションは中断します（ほぼ2か月後にこれが重要になることがわかった）。
このように見えた：
[fas6280a_1:wafl.nvlog.sm.sync.abort:notice]: NVLOG synchronization aborted for snapmirror source VOL_prod_ru, reason='Out of NVLOG files' [fas6280a_1:snapmirror.sync.fail:notice]: Synchronous SnapMirror from fas6280a_1:VOL_prod_ru to fas6280a_2:VOL_prod_ru failed.
彼らはケースをオープンし、NetAppエンジニアに直接相談しました-評決は常に同じように聞こえました-ネットワークに問題があります。 このテーマについて独自の調査を実施し、ほぼ1か月間費やしました。私たちの判断では、ネットワークは正常で、約0.5ミリ秒の負荷での待機時間であり、スキップしません。 解決策は、NetAppの深部から技術者の1人によって提案されました-Consistency Point（CP）メカニズム自体に関連するものがあるため、異なる方向で動作するべきではないと彼は言いました、まだ詳細を理解していませんでしたが、一方向に複製を展開する価値がありました-すべてが良くなりました。
これは私たちに合わなかったため、4つのディスクシェルフを購入し、すべてのRedo / UndoをFAS3270、メトロクラスターに移動し、クラスとして同期レプリケーションの問題を忘れました。 確かに、仮想マシンからの痙攣的な負荷、高いプロセッサ負荷、REDOの応答時間の高い要件により、この決定を維持することはできませんでしたが、これは別の話です。
問題2-非同期SnapMirror
ここではすべてが簡単です-同期を1分間に設定すると、割り当てられた時間内にデータがオーバーフローする時間がなく、変更が長すぎると見なされるため、終了しないセッションが取得されます。 5分ごとに停止し、各セクションごとに1分ずつシフトしました。 負荷がディスク使用率の80％に増加した場合、ピーク負荷時間（バックアップ、使用ディスクの90-95％など）で常に15-20分のオーダーの最も重いデータベースの同期ラグがあり、ラグは無限に増加します。 最良のケースで変更をロールバックするのは20分+レプリケーションの反転後の逆再同期であり、大きなパーティションでは非常に長い時間がかかるため、5分で切り替えができないことから、最良のケースでも同じ20分です。
問題3-QOSまたはNetAppの用語-FlexShare
システムはスケジューラを制御し、ボリュームレベルで動作し、他のボリュームとシステムプロセスを比較して、各ボリュームに1〜99の優先順位を設定できます。 説明は豪華で、すべてが2x2のように見えます。 実際には：
- ボリュームの上部バーを制限することはできません。アプリケーションが突然クラッシュし、I / Oを非常に苦しめ始めた場合、誰もが苦しむでしょう。
- 優先度がどのように設定されているかは関係ありません。たとえば、売上99、開発-1の場合、開発の負荷は売上に影響します。 しかし、はい、負荷が一定の場合、開発セクションの応答時間はわずかに悪くなります。
- 開発負荷が一定ではなくけいれん性の場合、優先順位はまったく機能しません。 彼は適応する時間が必要です。
- 優先順位は、システムがどれほど高くても、SnapMirrorの実行を高速化しません。
- 優先度は、システムの全体的なレイテンシを上げますが、それほど大きくはしません。 非常に高い負荷でのみ顕著です。
- コントローラーの負荷が非常に高い場合、ほとんどのコマンドを実行することはできません。コマンドが起動されてから3〜5分後に結果が得られます。たとえば、レプリケーションステータスも確認できず、クラスターソフトウェアの動作がブロックされます。
システムの優先度がオフになっているのは後者のためです。 彼らはこの問題に関するケースをオープンしました-結果はありません。
4番目の問題は、ユニットの空きスペース（1つのスペースに結合された複数のRAIDグループのセット）です。
過去数年のNetAppに出会った人は、おそらく集計が90％を超えるデータで満たされていると、システムが非常に遅延し、動作したくないことを知っているでしょう。 マーケティング担当者は、この問題はバージョン8.1から完全に解消されたと頑固に主張しています（正直なところ、8.0であっても正確には覚えていません）。 実際には-完全な嘘。 私たちは場所を追跡しませんでした。93％もユニットを埋めました-それだけです、こんにちは。 システム全体の応答時間は、ほぼ2倍に増加しました。 そして、これは、重複排除、圧縮、およびその他の利点を使用せず、シンプロビジョニングのみを使用する場合に提供されます。 システムは、最大85％のスペースを解放するときにのみリリースされました。 ポイント。
さらに、アグリゲートを85〜95％埋め、さまざまな方向のダーススナップミラーセッションを作成し、システムに80％I / Oをロードしてから、アグリゲートボリュームの1/5のパーティションを削除します。 結果-システムがそれ自体に侵入したという事実のために1時間以上動作しないデータベースがあり、すべてのセクションの応答時間は300ミリ秒から5秒の範囲でした。 コンソールに応答しませんでした。コントローラーを再起動することも考えましたが、最初はすべての負荷を緊急に取り除き、受信側のレプリケーションを強制終了し、しばらくしてシステムが回復し始めました。 NetAppの推奨事項-ファイルを一度に1つずつ削除します。voldestroyで12tbをすぐに削除しないでください。
5番目の問題-2ユニット
しかし冗談は、1台のユニットに100％ロードされたディスクがある場合、10％の負荷を持つ2台目のユニットは動作を拒否し、そのレイテンシは100％のユニットに匹敵するということです。 また、これは、NetAppへのデータの書き込み方法に直接関連しています。
実際には、ブロックサイズが特定の値（通常は16kbまたは32kbですが、設定可能）を超える場合、データを直接ディスクにドライブ（ライトスルー）できる従来のブロックストレージシステムとは異なり、NetAppはこれを行いません。 WAFLの性質上、本質的に常にライトバックを書き込みます。 これは、若いモデルであっても、コントローラーで大量のメモリを発生させるものです。 そして、これが記録の超低レイテンシーの原因であり、NetAppは、システムに大きな負荷がかかっていないことを誇りに思っています。 キャッシュはすべてのユニットで同じであり、オーバーフローし、アンロードされたユニットにも書き込みができなくなります。
結論-システム上で安定した低遅延が必要な場合は、ディスクを60％以上過負荷にしないでください。 同じドライブを使用している場合、別のユニットを作成することは意味がありません。
小さな結論
- 最大50 kmのDRソリューションを構築するタスクがある場合は、MetroClusterを使用し、それについても考えないでください。 価格差はばかげており、ホストに対して完全に透過的です。 マイナスの点-中心間に別個の暗い光学系が非常に望ましい。 しかし実際には、リソースを分割するときに機能し、チェックされます。 既存のSANに適合することができますが、私はあなたにそれを伝えませんでした。
- 低レイテンシを実現するタスクがある場合-ドライブに50〜60％（3.5インチSASディスクで90〜110 iops）を超えてロードさせないでください。
- 痙攣性の負荷を避けるようにしてください。負荷が線形であるほど、NetAppはそれを消化しやすくなります。
- 異なるブロックでロードしないようにしてください。 WAFLは非常に心配です。
- ユニットデータの負荷が85％を超えないようにしてください。
- 保証期間中にハードウェアを変更する準備をします。 たくさん。 しばしば。 しかし、これは現在、エントリーレベルおよび中間レベルのシステムのすべてのメーカーに影響を及ぼしています。
ここで、一般に、おそらくこれらのシステムとの通信の年についての私の観察すべて。 システムは実際にはそれほど悪くなく、非常に簡単に習得できます。 すべての快適な管理。