2009年10月に、すべてを再確認しました。 800ラックのデータセンターを構築する必要がありました。 私たちの直感、市場予測、アメリカの状況に基づいています。 論理的に聞こえるかのように思えたが、それは怖かった。
その後、ロシアには「クラウド」コンピューティングもクラウドホスティングもありませんでした。 実際、この言葉自体は市場ではほとんど使われていませんでした。 しかし、私たちはすでに、アメリカ全土でそのような設備が需要があることを見てきました。 500ノードの航空機設計者向けにHPCクラスターを作成する大規模なプロジェクトがあり、クラウドはコンピューティングクラスターと同じくらい大きいと考えました。
2009年には、クラウドが分散コンピューティング以外に使用されるとは誰も考えていなかったという間違いがありました。 誰もがCPU時間を必要としていると私たちは考えました。 そして、研究機関向けのHPCクラスターを構築する方法でアーキテクチャを構築し始めました。
そのようなクラスターが最新のクラウドインフラストラクチャとどれほど根本的に異なるか知っていますか？ 彼がディスクにアクセスする回数が非常に少なく、読み取り全体がほぼ一貫しているという事実。 タスクは単独で設定され、断片に分割され、各マシンが独自の断片を作成します。 その時点では、HPCクラスターとクラウドのディスクサブシステムの負荷プロファイルが根本的に異なることを誰も真剣に考慮していませんでした：最初のケースでは、これらはシーケンシャルな読み取り/書き込み操作であり、2つ目は完全なランダムです。 そして、これが私たちが直面しなければならない唯一の問題ではありませんでした。
ネットワークアーキテクチャ
最初の重要な選択は、メインクラウドプラットフォーム内のネットワーク用のInfiniBandまたはイーサネットでした。 長い間、InfiniBandを比較して選択しました。 なんで？ 繰り返しますが、最初にクラウドをHPCクラスターと見なしたのは、10Gb接続からすべてが組み立てられたためです。 InfiniBandは、素晴らしい速度、簡素化されたサポート、およびネットワーク運用コストの削減を約束しています。
2010年の最初の肩は10Gイーサネットでした。 当時、私たちはプラットフォームで初めて世界初のNicara SDNソリューションを使用し、後にVMwareが多額のお金で購入しました。これは現在VMware NSXと呼ばれています。 クラウドを構築することを学んだように、NiciraチームがSDNを行うことを学んだのと同じ方法です。 もちろん、何回かすべてが顕著に落ちたとしても、問題なくしてはできませんでした。 当時のネットワークカードは長時間の動作中に「衰退」しました。 Niciraからの次のメジャーアップデートの後、長い間、操作はvalerianで行われました。 しかし、56G InfiniBandが発売されるまでに、私たちはニシラの同僚と一緒に問題の一部をうまく処理し、嵐は静まり、誰もが安reliefのため息をつきました。
今日クラウドを設計した場合、おそらくそれをイーサネット上に置くでしょう。 それにもかかわらず、建築の正しい歴史はこの方向に進んだためです。 しかし、私たちに大きな利点を与えたのはInfiniBandであり、後で使用できます。
最初の成長
2011年から2012年にかけて、成長の第1段階が始まりました。 「アマゾンのように、ロシアでは安くしたい」が最初の顧客カテゴリです。 「特別な魔法が欲しい」-2番目。 クラウドをインフラストラクチャの円滑な運用のための奇跡のツールとして宣伝したという事実のために、顧客との間でいくつかの誤解がありました。 大規模な顧客はゼロに近い物理的なインフラストラクチャに慣れているという事実により、市場全体がすぐに大きな顧客に頭を痛められました。 サーバーが落ちた-部長へのre責。 また、仮想化の追加層と特定のオーケストレーションプールにより、クラウドは少し安定性の低い物理サーバーを実行します。 すべてがクラウドで手動でセットアップされ、状況を改善できる自動化およびクラスターソリューションを使用した人はいなかったため、VMの障害を扱うことは誰も望みませんでした。 Amazonは次のように述べています。「クラウド内のすべてが落ちる可能性がある」が、市場はそれを好まない。 顧客は、クラウドは魔法であり、すべてが中断することなく動作し、仮想マシン自体がデータセンター間で移行する必要があると考えていました...彼らはすべて、1つのサーバーインスタンスで1つの仮想マシンに移行しました。 そして、当時のIT開発のレベルは、自動化だけでは不十分でした。イデオロギー「動作する-触らない」に従って、彼らは一度すべてを手で行いました。 そのため、物理ホストを再起動するときに、すべての仮想マシンを手動で起動する必要がありました。 私たちのサポートも多くの顧客のためにこれに対処しました。 これは、内部サービスによって決定された最初のものの1つです。
誰がクラウドに来ましたか？ 最も異なる人々。 最初の1つは、分散型オンラインストアに到着し始めました。 その後、人々はビジネスに不可欠なサービスを通常のアーキテクチャに導入し始めました。 多くの人が、クラウドをフェイラバープラットフォーム、つまりデータセンターの予備のようなものだと考えていました。 それから彼らは主要なものについて移動したが、予備として2番目のサイトを去った。 このようなアーキテクチャの基盤をすでに構築している顧客は、依然として大多数に非常に満足しています。 失敗した場合に適切に構成された移行スキームは私たちの誇りでした-モスクワで大きな事故が発生した様子を見るのは非常にクールで、顧客サービスは自動的に予備に移行して展開しました。
ディスクとフラッシュ
最初の成長は非常に速かった。 アーキテクチャを設計するときに予想よりも高速。 すぐに鉄を買いましたが、ある時点でディスクの天井にぶつかりました。 ちょうどその時、3番目のデータセンターを設置しました。これは、クラウドの下で2番目で、将来のCompressorであり、稼働時間でT-IIIを認定しました。
2014年には、非常に大きな顧客が登場し、次の問題に直面しました-ストレージシステムの低下。 7つの銀行、5つの小売チェーン、旅行会社、地質調査を行っている研究機関がある場合、これらはすべてピーク負荷時に突然一致する可能性があります。
当時の典型的なストレージアーキテクチャは、ユーザーが書き込み速度のクォータを持っていることを前提としませんでした。 記録または読み取りの場合、すべてがライブキューの順序に配置され、その後、ストレージがすべてを処理しました。 そして、「ブラックフライデー」の売り上げがあり、ストレージユーザーがほぼ30倍減少したことがわかりました。小売業者は、ほぼすべての録音パワーの要求を小売しました。 診療所のサイトが崩壊し、15分間ページが開きました。 緊急に何かをする必要がありました。
通常は高価な、最も高性能なディスクアレイでも、パフォーマンスの優先順位を差別化する可能性はありませんでした。 つまり、顧客は依然として相互に影響を与える可能性があります。 ハイパーバイザーでドライバーを書き直すか、何か他のものを発明する必要がありました-そして緊急に。
100万IOPSの帯域幅を持つオールフラッシュアレイを購入することで問題を解決しました。 仮想ディスクあたり100,000 IOPSでした。 目にはパフォーマンスは十分でしたが、R / Wに制限を設ける必要がありました。 その時点（2014年末）のディスクアレイのレベルでは、問題は解決できませんでした。 私たちのクラウドプラットフォームは非独占的なKVM上に構築されており、そのコードに自由に登ることができます。 約9か月で、機能を慎重に書き直してテストしました。
現時点では、InfiniBandとAll-flashの組み合わせにより、まったくワイルドなことがわかりました。SLAが規定する最も厳しいペナルティを保証したパフォーマンスディスクを備えたサービスを市場で初めて導入しました。 そして市場では、競合他社は私たちを丸い目で見ていました。 「ディスクに100,000 IOPSを与えます。」 「これは不可能です...」私たち：「そして、私たちはまだそれを保証します。」 彼らは：「あなたは一般的に、ペスト、あなたはおかしいです。」 市場にとっては衝撃でした。 10の主要なコンテストのうち、8がCDのために勝ちました。 それから彼らは胸にメダルを掛けました。
16個のアレイ、それぞれ100万IOPSで、それぞれ40テラバイトになります！ それらはまだInfiniBandを介してサーバーに直接接続されています。 誰も考えもしなかった場所で爆発しました。 彼らはテストで6ヶ月間運転しましたが、ヒントさえありませんでした。
実際、アレイコントローラーがInfiniBandに到達すると、ルートは約30秒間再構築されます。 この時間を15秒に短縮できますが、それ以上はできません-プロトコル自体に制限があるためです。 顧客が自分で作成した仮想ディスクが一定数に達すると、オールフラッシュストレージコントローラーを備えた珍しいヘイゼンバッグが表示されることが判明しました。 新しいディスクを作成するように要求された場合、コントローラーは気が狂い、100％の負荷がかかり、サーマルシャットダウンになり、同じ30秒のスイッチを生成できます。 ディスクがvirtualokから落ちます。 セーリング。 数か月間、ストレージベンダーと一緒にバグを探していました。 その結果、彼らはそれを発見し、アレイ上のコントローラーのマイクロコードを制御してくれました。 この間、問題を解決できるように、これらの配列の周りにレイヤー全体を作成しました。 また、制御スタックのほぼ全体を書き直さなければなりませんでした。
配列の動機付けは、これまでサポートから外れています。
私たちの日々
その後、リモートワークステーション用のソフトウェアに問題がありました。 そこでは、ソリューションはプロプライエタリであり、ベンダーとの対話は次のとおりでした。
「助けてくれませんか？」
-いいえ。
「あなたはいまいましい、私たちはあなたについて不平を言うでしょう。」
-お願いします。
この時点で、独自のコンポーネントを放棄することを決定しました。 その後、その開発によってニーズが閉じられました。 私たちは現在、オープンソースプロジェクトに投資しています-かつてALT Linuxにほぼ6か月の予算を提供したという話のように、時には私たちの要求が必要な開発の開発を劇的に加速しました。 同時に、ヨーロッパの同僚が「すごい」と言ったように、私たちはこの波の発展を州にもたらしました。
今日、経験豊富な外観でクラウドを見て、数年前からクラウドをさらに開発する方法を理解しています。 また、開発リソースがあるため、 KVMで何でもできることを理解しています。