保険-銀行やモバイルオペレーター、「重い」IT鉄の消費者に次いで3番目。 作業開始時の状況は次のとおりでした。ある会社のオフィスには、中央のサーバールーム（小さなデータセンターの機械に似ています）があり、一般に、すべてが正常に機能していました。
問題は、サーバールームのラックの下（およびラック自体の中）の場所が2年前に終わったことです。 他の2つのデータセンターには場所がありましたが、ここにはありませんでした。
2番目の問題は、サーバーのスイスチーズのように、主な生産拠点が物理的に149ボリュームにあることです。 これは、それを増やす必要があったときに、物理ディスクに最初の空き穴を見つけてそこに押し込んだためです。 データベースボリューム間には、他のプロジェクト、ソフトウェア、さまざまな一時ファイルなどのデータベースが存在する場合があります。 一般的に、順序を復元する必要がありました。
別の興味深い機能-新しいデータが表示されたとき、それらの新しいボリューム（LUN）が必要でした。 彼らは彼をカットし、彼はすぐにボトルネックになりました。 説明は非常に簡単です-戦闘基地では、最も負荷の高い場所は新しいデータです。 そして、それらが1つのディスクに物理的に配置されている場合、その最大読み取り/書き込み速度は、実際にはシステム全体を制限します。
オプションは次のとおりです。
•既存のアレイのアップグレード（検討：高価で非効率的で、置く場所がありません）。
•同じアレイの新世代への移行（メンテナンスのコストが高く、継続的なチューニング）。
•代替ソリューションを検索します（フラッシュの誤計算とテスト）。
変更点
独自のベースを備えた別個のサブプロジェクトである小さなデータから始めることにしました。 それをテストしてから、ゆっくりとスムーズに新しいシステムに移行します。 当然、作業が始まる前にすべてがそこで機能していました。 より速く、より正確に動作するようにしたかっただけです。 このデータはSymmetrix DMX-3上にありました。
ヴァイオリン6264ユニットを3台持ち込み、シャーマニズムを開始しました。 そもそも、彼らは基地の最適な物理的構造のためにオラクル主義者と一緒に座った。 常識、OSの機能、およびベースのアーキテクチャを考慮して、149ではなく27のボリュームが必要であると判断しました。その後、さらに2つがカットされ、29になりました。同時に、ところで、新しいものを切り刻むために、それはスキップされます。 その結果、空き領域の約15％が、独立したデータ間の「ギャップ」に費やされました。
もちろん、これはパフォーマンスの点でまだ最適化されていません。 DMXでは、1つのボリュームが7つの物理ディスクに配置できます。 Violinでは、コントローラー自体のアーキテクチャーと工場データ配置アルゴリズムにより、LUNはストレージ全体に分散されます。これにより、脱穀サーバーが数ギガバイトのサイズの特定のセクションに固執することを決定した場合でも、最大のパフォーマンスを得ることができます。
明らかに、単純なものに同意しなければなりませんでした。 時には方法がありません、男性の決定を下す必要があります。 しかし、ずっと後に、別のより大きなデータベースがスタンバイを介して作成されました。メインデータベースがコピーされ、30分だけ読み取り、その後再び記録することができます。
彼らは土曜日の夜遅くに基地を使用し、構造を変更し、データをコピーして、新しいハードウェアに持ち込みました。 測定を行い、すべてがOKです。 実動で発生します-動作し、一般的には正常に動作しますが、期待したほど高速ではありません。 ストレージリソースが完全に使用されなかったという意味で。
フローのプロファイルを開始しました-計算サーバー自体がボトルネックになっていることがわかりました。 以前は、ストレージシステムがより多くを提供できるという事実にもかかわらず、ストレージからの応答を待って、最大限に脱穀し始めました。 その結果、顧客は非常に感銘を受け、2つの新しい「ボックス」を購入しました。1つはこのベース用で、もう1つはメインのすぐ下の「成長用」です。
新しいサーバーで、彼らは彼らが望むものを手に入れました。 テストは終了し、結果は良好です。顧客はさらにスケーリングを検討し、段階的に鉄を使ってゆっくりと落ち着いて購入します。
楽しいのは、基地のアーキテクチャに関する問題が解決されたこと、速度の向上の問題、サーバールームの物理的なスペースの問題、来年発生する電力の問題などです。 3年目の運用に適した、かつて高かったDMXを取り外すことは少し残念でしたが、これはすべての鉄の運命です。 おそらく彼は彼の新しい人生をどこかで見つけるでしょう。
なぜバイオリン？
Habrのお気に入りの質問は、なぜそんなに宇宙的に高価な鉄なのかということです。 はい、 オーバーヘッドHDDテクノロジーのない「本物の」（SSDの棚からではなく ） アレイのように、バイオリンはユニットあたり非常に高価です。 問題は、システム全体で数十万ドルです。 一方、ここでの話はこれです-深刻なデータにフラッシュアレイを使用できる場合、将来的には非常にうまくいくため、間違いなくバイオリンを購入できます。 インストールには費用がかかります-運用することは有益です。
当然のことながら、より安価なソリューションがありますが、私たちのタスクにはさらにいくつかの重要な要件がありました。
- 24時間365日の基本可用性。 テストのために取った部分は、保険ケースの主要な分析です。 大まかに言えば、これは係数の推定値であり、リアルタイムでは必要ありません。 データを取得し、グラインドし、数式を更新しました。 必要に応じて消火して停止することができます。 実際、メインベースの負荷のピーク時に、彼女が優先され、計算のこの部分は禁止されました。 しかし、戦闘基地はいかなる場合でも消滅させることはできず、常に機能するはずです。 数分のダウンタイムでさえ、数百万ルーブルの費用がかかります。 したがって-唯一のハイエンド。
- 良いSLAで適切なサポートが本当に必要です。 このようなシステムでは、複製が常に使用され、2番目の回路の故障は重大な事故と見なされます。 ベースとサービスは切り替えられますが、すぐに修理に行く必要があります。これは、予備の機器も落下した場合、これで終わりだからです。 ここから-モスクワのスペアパーツ倉庫、有能なエンジニアは、誰かが来て決定することを保証します。 一般的に、いつものように。 たとえば、Dellサーバーにサービスを提供している同僚の話を次に示します。
さらに
ステージは次のとおりです。
- 誤算と分析（特に重要な問題は、実装後の実際の運用コストが低いことでした）。
- 私たちとテストします。
- OLAPの最初の配列を購入します。
- わあ！ Oracleは少なくとも2倍は良いと感じています;専門家は必要ありません。
- 私たちは6ヶ月待っています。 作業の6か月以内に注意する必要はありません。
- もう一度、ケースを検討してください。 1 TBのコストは、ハイエンドソリューションよりも低くなっています。
バイオリンGUI
Oracle Databaseパフォーマンス統計アプリケーション
テストの6か月後、2番目のセクションのアップグレードを開始しました。 競争がありましたが、これもバイオリンとの決定の勝利でした。 私の知る限り、顧客はまだVNXと日立とみなされ、さらにシステムが混在していました。 バイオリンは完全なフラッシュでもあるにもかかわらず、最も安価であることが判明しました。 サーバールームにはまだ多くの古いストレージシステムがありますが、重要で生きているものはすべてフラッシュ上にあります。
ご覧のとおり、この例は興味深いものです。 このケースをバイオリンのみの競争と見なしてほしい場合-VBolotnov@croc.ruに書いて、あなたの状況でこのように最適化しようとするのが理にかなっていると言います。