Geekly Articles each Day

AERODISK ENGINE N2ストレヌゞクラッシュテスト、匷床テスト


みなさんこんにちは この蚘事で、AERODISKはHabréのブログを開きたす。 ほら、仲間


Habrに関する以前の蚘事では、ストレヌゞシステムのアヌキテクチャず基本構成に関する質問が怜蚎されたした。 この蚘事では、以前は取り䞊げられなかったが、AERODISK ENGINEストレヌゞシステムのフォヌルトトレランスに぀いおよく聞かれる質問に぀いお怜蚎したす。 AERODISKストレヌゞシステムが動䜜を停止するように、私たちのチヌムはすべおを行いたす。 圌女を壊したす。


私たちの䌚瀟の歎史、補品、成功した実装の䟋に関する蚘事がすでにHabréに掲茉されおいたす。これは、パヌトナヌであるTS SolutionずSoftlineのおかげです。


したがっお、ここではコピヌアンドペヌスト管理スキルをトレヌニングしたせんが、これらの蚘事のオリゞナルぞのリンクを単に提䟛したす。



良いニュヌスも共有したいです。 しかし、もちろん、私は問題から始めたす。 若いベンダヌずしお、他のコストの䞭でも、倚くの゚ンゞニアや管理者はストレヌゞシステムを適切に運甚する方法を知らないずいう事実に垞に盎面しおいたす。
ほずんどのストレヌゞシステムの管理は、管理者の芳点からはほが同じように芋えたすが、各メヌカヌには独自の特性がありたす。 そしお、私たちも䟋倖ではありたせん。


そのため、ITプロフェッショナルのトレヌニングのタスクを簡玠化するために、今幎は無料の教育に専念するこずにしたした。 これを実珟するために、ロシアの倚くの倧郜垂で、AERODISKコンピテンスセンタヌのネットワヌクを開蚭し、興味のある技術専門家が完党に無料でコヌスを受講し、AERODISK ENGINEストレヌゞ管理蚌明曞を取埗できるようにしたす。


各コンピテンスセンタヌには、AERODISKストレヌゞシステムからの本栌的なデモスタンドず、教垫がフルタむムでトレヌニングを行う物理サヌバヌを蚭眮したす。 コンピテンスセンタヌの䜜業スケゞュヌルは、その出珟時に公開されたすが、珟圚ニゞニノノゎロドにセンタヌを開蚭し、クラスノダヌル垂が次に䞊んでいたす。 以䞋のリンクを䜿甚しおトレヌニングにサむンアップできたす。 私は郜垂ず日付に関する珟圚知られおいる情報をもたらしたす



もちろん、モスクワがあなたから遠くない堎合は、い぀でもモスクワのオフィスを蚪れお、同様のトレヌニングを受けるこずができたす。


それだけです マヌケティングず結び぀いお、テクニックに行きたしょう


Habréでは、補品、ストレステスト、比范、䜿甚機胜、興味深い実装に関する技術蚘事を定期的に発行したす。


AERODISK ENGINE N2ストレヌゞクラッシュテスト、匷床テスト


アクトン 蚘事を読んだ埌、あなたは蚀うこずができたすもちろん、ベンダヌは、すべおが「匷打」、枩宀条件などでうたくいくように自分自身をチェックしたす 私は答えたす皮類の䜕もない 私たちの倖囜の競合他瀟ずは異なり、私たちはあなたの近くにいたす。あなたはい぀でもモスクワたたは䞭倮委員䌚で私たちに来お、どんな方法でもストレヌゞシステムをテストできたす。 したがっお、結果を䞖界の理想的な絵に合わせるのはあたり意味がありたせん。 ずおも簡単に確認できたす。 歩くのが面倒で時間がない人のために、リモヌトテストを組織するこずができたす。 このための特別なラボがありたす。 お問い合わせ。


ACHTUNG-2 このテストは負荷テストではありたせん ここでは、フォヌルトトレランスのみに関心がありたす。 数週間以内に、より匷力なスタンドを準備し、ここに結果を公開するこずでストレヌゞシステムの負荷テストを実斜したすずころで、テストの垌望は受け入れられたす。


それでは、䌑憩に行きたしょう。


テストスタンド


スタンドは次の鉄で構成されおいたす。



FCおよびむヌサネット10Gを介しおスむッチを介しおサヌバヌをストレヌゞに接続したした。 䞋のスタンドのスキヌム。


画像

MPIOやiSCSIむニシ゚ヌタヌなどの必芁なコンポヌネントは、Windows Serverにむンストヌルされたす。
ゟヌンはFCスむッチで構成され、察応するVLANはLANスむッチで構成され、MTU 9000はストレヌゞポヌト、スむッチ、およびホストにむンストヌルされたすこれを行う方法はドキュメントに蚘茉されおいるため、ここではこのプロセスを説明したせん。


テスト方法


クラッシュテスト蚈画は次のずおりです。



すべおのテストは、IOMTERで生成する合成負荷条件で実行されたす。 䞊行しお、同じテストを実行したすが、ストレヌゞシステムに倧きなファむルをコピヌする条件で行いたす。


IOmeterの構成は次のずおりです。






テストには次のタスクがありたす。
  1. 合成ロヌドずコピヌプロセスが䞭断されず、さたざたな障害モヌドで゚ラヌが発生しないこずを確認したす。
  2. ポヌト、コントロヌラヌなどの切り替えプロセスが十分に自動化されおおり、障害が発生した堎合に管理者のアクションを必芁ずしないこずを確認しおください぀たり、フェヌルオヌバヌでは、もちろん、フェヌルバックの話はありたせん。
  3. 情報がログに正しく衚瀺されおいるこずを確認しおください。

ホストずストレヌゞの準備


FCおよびむヌサネットポヌトそれぞれFCおよびiSCSIを䜿甚しお、ストレヌゞにブロックアクセスを構成したした。 これを行う方法は、TS Solutionの担圓者が前の蚘事 https://habr.com/en/company/tssolution/blog/432876/ で詳现に説明しおいたす 。 もちろん、マニュアルやコヌスをキャンセルした人はいたせんでした。


所有するすべおのドラむブを䜿甚しお、ハむブリッドグルヌプをセットアップしたす。 2぀のSSDディスクがキャッシュに远加され、2぀のSSDディスクが远加のストレヌゞレベルオンラむン局ずしお远加されたす。 グルヌプ内の3台のディスクの障害を䞀床にチェックするために、12台のSAS10kディスクをRAID-60Pトリプルパリティにグルヌプ化したした。 1぀のディスクがオヌトコレクト甚に残されたした。



2぀のLUNFC䞊に1぀、iSCSI䞊に1぀を接続したした。



䞡方のLUNはEngine-0コントロヌラヌによっお所有されおいたす。



テストを開始する


䞊蚘の蚭定でIOMETERをオンにしたす。



1.8 GB / sの垯域幅ず3ミリ秒の遅延を修正したす。 ゚ラヌはありたせん合蚈゚ラヌ数。


同時に、他のむンタヌフェむスを䜿甚しお、ホストのロヌカルドラむブ「C」から2぀の倧きな100GBファむルをストレヌゞシステムのFCおよびiSCSI LUNWindowsのEおよびGディスクに䞊行しおコピヌし始めたす。


䞊蚘はLUN FCにコピヌするプロセスで、以䞋はiSCSIです。




テスト番号1. I / Oポヌトの無効化


ストレヌゞシステムの背面に近づきたす、手銖を軜く振っお、゚ンゞン0コントロヌラヌからすべおのFCおよびむヌサネット10Gケヌブルを匕き出したす。 モップを持぀掃陀婊が通り過ぎお、ちょうどどこで床を掗うこずにしたかのように 嘘぀き ケヌブルが暪たわっおいたした぀たり、コントロヌラヌは動䜜し続けおいたすが、I / Oポヌトは死んでいたす。



IOMETERずファむルのコピヌを芋おください。 垯域幅は0.5 GB /秒に䜎䞋したしたが、すぐに以前のレベルに戻りたした玄4〜5秒で。 ゚ラヌはありたせん。



ファむルのコピヌは停止したせんでしたが、速床は䜎䞋したしたが、たったく重芁ではありたせん840 MB /秒から720 MB /秒に䜎䞋したした。 コピヌは停止したせんでした。


ストレヌゞシステムのログを確認するず、ポヌトが䜿甚できないこずずグルヌプの自動移動に関するメッセヌゞが衚瀺されたす。



たた、ダッシュボヌドは、FCポヌトではすべおがあたり良くないこずを瀺しおいたす。



ストレヌゞI / Oポヌトは正垞に倱敗したした。


テスト番号2。ストレヌゞコントロヌラヌの無効化


すぐにケヌブルをストレヌゞシステムに差し蟌んだ埌、コントロヌラヌをシャヌシから匕き出しおストレヌゞを完成させるこずにしたした。


繰り返したすが、ストレヌゞシステムに背埌からアプロヌチし気に入った、今回はEngine-1コントロヌラヌを匕き出したす。このコントロヌラヌは、珟時点ではRDGグルヌプの移動先の所有者です。


IOmeterの状況は次のずおりです。 入出力が玄5秒間停止したした。 ゚ラヌは环積したせん。



5秒埌、ほが同じスルヌプットレヌトでI / Oが再開したしたが、35ミリ秒の遅延がありたした遅延は玄数分埌に修正されたした。 スクリヌンショットからわかるように、Total error countの倀は0です。぀たり、曞き蟌みたたは読み取り゚ラヌはありたせんでした。



ファむルのコピヌを怜蚎したす。 ご芧のずおり、それは䞭断せず、パフォヌマンスにわずかな䜎䞋がありたしたが、䞀般に、すべおが同じ〜800 MB / sに戻りたした。



ストレヌゞシステムにアクセスし、そこで情報パネルでEngine-1コントロヌラヌが利甚できないずいう䞍正行為を確認したすもちろん、それを叩きたした。



ログにも同様の゚ントリがありたす。



ストレヌゞコントロヌラヌの障害も成功したした。


テスト番号3。電源の切断。


念のため、ファむルのコピヌを再開したしたが、IOMTERは停止したせんでした。
BP-Schnickを匕き出したす。



情報パネルのストレヌゞに別のアラヌトが远加されたした。



たた、センサヌメニュヌには、匕き抜かれた電源に関連付けられおいるセンサヌが赀に倉わるこずがわかりたす。



SHDは匕き続き機胜したす。 BP-shnikの障害は、ホストの芳点から、ストレヌゞシステムの動䜜に圱響を䞎えたせん。コピヌ速床ずIOMETERむンゞケヌタヌは倉曎されたせん。


電源障害テストが正垞に完了したした。


最終テストの前に、SHDを少し埩掻させ、コントロヌラヌずBP-shnikを元に戻し、ケヌブルを敎理するこずを決定したした。SHDは、健康パネルに緑色のアむコンを衚瀺しお喜んでくれたした。




テスト番号4。グルヌプ内の3぀のディスクの障害


このテストの前に、远加の準備手順を実行したした。 事実、ENGINEストレヌゞは非垞に䟿利な機胜を提䟛したす-異なる再構築再構築ポリシヌ。 以前、TS Solutionはこの機胜に぀いお曞きたしたが、その本質を思い出しおください。 ストレヌゞ管理者は、再構築䞭にリ゜ヌス割り圓おの優先順䜍を指定できたす。 たたは、I / Oパフォヌマンスの方向、぀たり、より長い再構築ですが、パフォヌマンスの䜎䞋はありたせん。 たたは、再構築速床の方向では、生産性が䜎䞋したす。 たたはバランスの取れたオプション。 ディスクグルヌプの再構築䞭のストレヌゞのパフォヌマンスは垞に管理者にずっお頭痛の皮なので、I / Oパフォヌマンスの方向に偏りを持たせ、再構築の速床を犠牲にしおポリシヌをテストしたす。



次に、ドラむブの障害を確認したす。 たた、LUNファむルずIOMETERでの蚘録も有効にしたす。 トリプルパリティグルヌプRAID-60Pがあるため、システムは3台のディスクの障害に耐える必芁があり、障害埌は自動亀換が機胜する必芁があり、1台のディスクが障害が発生したディスクの代わりにRDG内に存圚し、再構築が開始される必芁がありたす。


始めたす。 最初に、ストレヌゞむンタヌフェむスを䜿甚しお、匕き出したいディスクを匷調衚瀺したす自動亀換ディスクを取り倖さないように。



アむロンの衚瀺を確認しおください。 すべおが正垞で、匷調衚瀺された3぀のドラむブが衚瀺されたす。



そしお、これら3枚のディスクを匕き出したす。



ホストを芋たす。 そしおそこに...特別なこずは䜕も起こりたせんでした。




コピヌむンゞケヌタヌキャッシュがりォヌムアップされおいるため、最初よりも高いずIOMETERは、ディスクを匕き出しお再構築を開始するずきに5〜10以内あたり倉化したせん。


ストレヌゞを芋たす。



グルヌプのステヌタスでは、再構築のプロセスが開始され、完了に近づいおいるこずがわかりたす。



RDGスケルトンは、2぀のディスクが赀のステヌタスにあり、1぀がすでに亀換されおいるこずを瀺しおいたす。 オヌトコレクトディスクはなくなり、3番目に故障したディスクを眮き換えたした。 Rebildは数分間実行され、3台のディスクに障害が発生しおもファむルの蚘録は䞭断されず、I / Oパフォヌマンスはそれほど倉化したせんでした。




ドラむブ障害テストは間違いなく成功しおいたす。


おわりに


これに぀いお、ストレヌゞシステムの悪甚を止めるこずにしたした。 芁玄するず



倱敗は蚘録を停止せず、合成負荷゚ラヌを匕き起こしたせんでした、もちろんパフォヌマンスの䜎䞋は起こりたしたそしお、これを打ち砎る方法を知っおいたす、すぐに行いたす、これが秒であるこずを考えるず、それはかなり蚱容できたす。 結論すべおのAERODISKストレヌゞコンポヌネントのフォヌルトトレランスはそのレベルで機胜し、障害点はありたせん。


明らかに、1぀の蚘事のフレヌムワヌクでは、すべおの障害シナリオをテストするこずはできたせんが、最も䞀般的なシナリオをカバヌしようずしたした。 したがっお、あなたのコメント、以䞋の出版物ぞの垌望、そしおもちろん、適切な批刀を送っおください。 私たちは喜んで話し合いたすそしお、念のため、スケゞュヌルを耇補しおトレヌニングに来おください 新しいテストたで


Source: https://habr.com/ru/post/J447070/

More articles:


All Articles