データセンターで5つのプレースメントの動物園をどのようにすくい上げるか

それはすべて、MSUホステルのsistemnikと、多くの皆さんが見た列車のスケジュールをホストする通常のホスティングから始まりました。また、負荷制限を満たすために夜間にファイルを転送します。その後、最初のサーバーが登場しました。彼らは5月にトリプルトラフィックを受信したため、すぐに就寝しました。より正確には、彼らがどのようなトラフィックを受け取ったかはわかりません。なぜなら、彼らは通常のものから正確にトリプルに嘘をついたからです。







振り返ると、それ以降のすべての配置アクションは強制移動です。そして今、15年目で、インフラストラクチャを必要な方法で構成できるようになりました。



現在、暗い光学リングで接続された4つの物理的に異なるデータセンターに立っており、5つの独立したリソースプールをそこに配置しています。そして、たまたま、隕石が交差点の1つに落ちると、これらのプールの3つはすぐに落ち、残りの2つは負荷を引っ張らないでしょう。したがって、順序を復元するために完全なリバランスを行いました。

最初のデータセンター

最初はデータセンターはありませんでした。モスクワ州立大学の寮に古い組織家がいました。次に、ほとんどすぐに-Masterhostでの共有ホスティング（彼らはまだ生きています、地獄）。列車のスケジュールが設定されたサイトへのトラフィックは4週間ごとに2倍になりました。そのため、すぐにKVM-VPSに切り替えましたが、2005年頃に発生しました。ある時点で、着信と発信のバランスを維持する必要があったため、トラフィック制限に遭遇しました。 2つのインストールがあり、必要な比率を維持するために、毎晩、いくつかの重要なファイルを一方から他方にシフトしました。



2009年3月にはVPSしかありませんでした。これは良いことです。コロケーションに切り替えることにしました。いくつかの物理的な鉄のサーバーを購入しました（そのうちの1つは壁からのもので、本体はメモリとして格納されています）。私たちはフィヨルドをデータセンターに置きました（そして、彼らはまだ生きています、悪魔）。どうして？それは当時のオフィスからそれほど遠くないので、友人が勧め、私はすぐに起きなければなりませんでした。さらに、それは比較的安価でした。



サーバー間で負荷を共有するのは簡単でした。それぞれにマスタースレーブレプリケーションを備えたMySQLのバックエンドがあり、フロントはレプリカと同じ場所にありました。まあそれは負荷の種類による分離はほとんどありません。間もなく彼らも見逃し始め、3分の1を購入しました。



2009年10月1日頃に、サーバーの数はすでに増えていることに気づきましたが、今年は横になります。トラフィックの予測は、可能な容量がマージンで切り捨てられることを示しました。そして、データベースのパフォーマンスに遭遇しました。トラフィックが増加する前に準備するのに1か月半ありました。これが最初の最適化の時でした。純粋にデータベース用にいくつかのサーバーを購入しました。 15krpmの高速ディスクに重点を置いていました（SSDを使用しなかった正確な理由は覚えていませんが、書き込み操作の数に制限があり、同時に飛行機と同じくらいのコストがかかりました）。フロント、バック、ベースを分割し、nginx、MySQLの設定を微調整し、SQLクエリを最適化するためにサイズ変更を行いました。生き残った。





これで、Tier-IIIデータセンターのペアとUIによってTier-IIに移動しました（T3でスイングしますが、証明書はありません）。しかし、フィヨルドはT-IIでさえなかった。彼らは存続性に問題があり、「すべての電力線が1つのコレクター内にあり、火事があり、発電機が3時間運転していた」というカテゴリーの状況がありました。一般的に、私たちは引っ越すことにしました。



別のデータセンターであるキャラバンを選択。課題：ダウンタイムなしでサーバーを移動する方法？しばらくの間、2つのデータセンターに住むことにしました。幸い、当時のシステム内のトラフィックは現在ほどではなく、しばらくの間（特に季節外れ）にVPNを介してロケーション間でトラフィックを駆動することが可能でした。バランスの取れたトラフィック。しばらくして完全に引っ越してキャラバンのシェアを徐々に増やしました。これで、データセンターが1つ残っています。そして、私たちは2つ必要です。フィヨルドでの失敗のおかげで、私たちはすでにこれを理解しています。当時を振り返ると、TIER IIIは万能薬ではなく、生存率は99.95ですが、可用性は異なります。したがって、99.95以上の可用性を実現するには、1つのデータセンターでは十分ではありません。Stordataが2番目に



選ばれた、そしてすでにキャラバンサイトとの光リンクの可能性がありました。最初のコアを拡張することができました。キャラバンがお尻を持っていると発表したので、新しいデータセンターをロードし始めました。建物が取り壊されたため、彼らはサイトを離れる必要がありました。既に。驚き！新しいサイトがあり、すべてを消す、クレーン付きの機器でラックを持ち上げる（その後、2.5の鉄製のラックがあった）、翻訳してオンにする、すべてが機能する...すべてに4時間...おとぎ話... 1時間のダウンタイムさえあることはすでに沈黙しています収まりませんでしたが、ここでは少なくとも1日は話が長引いていました。そして、これらはすべて「すべてがなくなって、石膏が取り除かれ、クライアントが去る！」という精神で提示されました。最初の電話である9月29日と10月10日に、彼らはすべてのものを手に入れようとしました。 3〜5日間、移動計画を立てる必要があり、3つの段階で、サービスと稼働時間を完全に維持しながら一度に機器の3分の1をオフにし、車をStordataに輸送します。その結果、ダウンタイムは15分であり、最も重要なサービスではありませんでした。



そのため、データセンターは1つになりました。



現時点では、サーバーを手に持って荷物を運んだり、ローダーを遊んだりすることにうんざりしています。さらに、データセンター内のハードウェア自体の扱いにうんざりしています。彼らはパブリッククラウドに目を向け始めました。

2から5（ほぼ）のデータセンター

クラウドのオプションを探し始めました。私たちはクロクに行き、試して、テストし、条件について合意しました。Compressorのデータセンターにあるクラウドに入りました。彼らは、Stordata、Compressor、そしてオフィスの間に暗い光学系のリングを作りました。どこでもそのアップリンクと光学の2つの肩があります。光線を切断してもネットワークは破壊されません。アップリンクが失われてもネットワークは破壊されません。LIRステータスを取得し、独自のサブネット、BGPアナウンス、ネットワーク、美容を確保しました。ネットワークの観点からクラウドにどのように移行したかは説明しませんが、ニュアンスがありました。



したがって、2つのデータセンターがあります。



Krokはまた、Volochaevskayaにデータセンターを持ち、そこでクラウドを拡張し、リソースの一部をそこに転送することを提案しました。しかし、実際にはデータセンターの解体後に復旧しなかったキャラバンの話を思い出して、会社が存在しなくなるリスクを減らすために、さまざまなプロバイダーからクラウドリソースを取得したいと思いました（国はそのようなリスクを無視することができないほどです）。そのため、Volochaevskayaへの連絡はありませんでした。まあ、2番目のベンダーも価格の魔法をかけています。あなたが弾力的にピックアップして去ることができるとき、それは価格に関して強力な交渉ポジションを与えるからです。



さまざまなオプションを検討しましたが、選択は#CloudMTSにありました。これにはいくつかの理由がありました：テストのクラウドが優れていることが証明された、彼らはネットワーク（結局、通信事業者）との連携方法も知っている、そして結果として興味深い価格で市場を獲得するという非常に積極的なマーケティングポリシーです。



合計3つのデータセンター。



その後、Volochaevskayaも接続しました-追加のリソースが必要でしたが、Compressorは既に少し窮屈でした。一般的に、3つの雲とStordat内の機器の間で負荷を再分散しました。



4つのデータセンター。そして、存続可能性に関しては、T3はどこにでもあります。誰もが証明書を持っているように見えるわけではありませんが、確実には言えません。



MTSにはニュアンスがありました。 MGTSだけが最後のマイルにそこに行くことができました。同時に、MGTSの暗い光学系を完全にデータセンターからデータセンターに引き寄せることはできませんでした（長い間、それは高価であり、私がそれらを混同しない限り、それらはそのようなサービスを提供しません）。私はそれをジョイントで行う必要があり、データセンターから最も近いウェルに2つのビームを出力しました。そこには、ダークオプティクスマスターテルのプロバイダーがあります。彼らは都市全体に広範な光学ネットワークを持っています。そして、どちらかと言えば、彼らは望ましいルートを溶接してあなたに脈を与えます。その間に、冬の雪のように、突然、ワールドカップが街にやって来て、モスクワの井戸へのアクセスが閉鎖されました。私たちはこの奇跡が終わるのを待っていました、そして私たちは私たちのリンクを投げることができます。 MTSのデータセンターに光学系を取り付けたままにし、口笛を吹いて希望のハッチに到達してそこに降ろす必要があったようです。条件付き。彼らは3ヶ月半をしました。より正確には、最初の光線は非常に速く作られました、8月の初めまでに（ワールドカップは7月15日に終了したことを思い出させてください）。しかし、私は2番目の肩をいじくり回さなければなりませんでした。最初のオプションは、Kashirskoye高速道路を掘る必要があったことを意味しました。そのため、1週間遮断する必要がありました（再建にはトンネルがあり、通信があったため、掘り出す必要がありました）。幸い、別のルートを見つけました。別のルートで、同じ地理的に独立しています。このデータセンターから、私たちの存在のさまざまなポイントへの2つの筋が判明しました。光学リングはペンでリングに変わりました。このデータセンターから、私たちの存在のさまざまなポイントへの2つの筋が判明しました。光学リングはハンドル付きのリングになっています。このデータセンターから、私たちの存在のさまざまなポイントへの2つの筋が判明しました。光学リングはハンドル付きのリングになっています。



少し先に進んで、とにかく彼らが私たちにそれを置いたと言います。幸いなことに、運用開始当初はあまり転送されていませんでした。 1つの井戸で火災が発生し、設置業者が泡で悪態をついていた間に、2番目の井戸で誰かがコネクターを引き抜いて確認しました（どういうわけか、新しいデザインのようでした）。数学的には、同時失敗の可能性はごくわずかです。実際、彼を捕まえた。実際、私たちはフィヨルドで幸運でした-主電源がそこで切られました、そしてそれを再びオンにする代わりに、誰かがスイッチを混乱させてバックアップラインをオフにしました。



場所間で負荷を分散するための技術的な要件だけでなく、奇跡もありません。価格が適切な積極的なマーケティングポリシーは、リソース消費の一定の成長率を意味します。そのため、MTSに送信する必要があるリソースの割合を考慮しました。他のすべてのデータセンター間で、その他すべてをほぼ均等に再分散しました。

再びあなたの鉄

パブリッククラウドを使用した経験から、実験用、パイロット用など、リソースをすばやく追加する必要がある場合は、パブリッククラウドを使用すると便利です。一定の負荷の下で使用すると、鉄をねじるよりも高価になります。しかし、コンテナーの概念、クラスター内の仮想マシンのシームレスな移行などを放棄することはできませんでした。私たちは夜間にいくつかの車を消すために自動化を書きましたが、それでも経済はうまくいきませんでした。プライベートクラウドをサポートするのに十分な専門知識がなかったため、プライベートクラウドを拡大する必要がありました。



私たちは、ハードウェアにクラウドを比較的簡単に導入できるソリューションを探していました。当時はシスコのサーバーを使用したことがなく、ネットワークスタックのみを使用していたため、これはリスクでした。デルでは、これはシンプルで有名なアイアンで、カラシニコフ突撃銃として信頼できます。これは何年も前からありましたが、まだどこかに存在しています。しかし、Hyperflexの背後にある考え方は、そのままで最終的なソリューションのハイパーコンバージェンスをサポートするということです。そして、Dellaではすべてが通常のルーター上にあり、ニュアンスがあります。特に、オーバーヘッドが原因で、パフォーマンスは実際にはプレゼンテーションほどクールではありません。つまり、それらは正しくセットアップでき、それは非常に優れたものになりますが、これは私たちのビジネスではないと判断し、これを職業とする人々が準備できるようにしました。その結果、Cisco Hyperflexを選択しました。このオプションは、最も興味深いものとしてまとめて勝ちました：設定と操作における痔の減少、そして、テスト中はすべて順調でした。 2019年の夏に、私たちはクラスターを戦闘に投入しました。 Compressorには半分空のラックがあり、大部分はネットワーク機器のみで占められていました。したがって、5番目の「データセンター」を取得しました。物理的には4つですが、リソースプールでは5つです。



彼らは、一定の負荷の量と変数の量を計算しました。彼らは定数を自分のアイアンの負荷に変えました。しかし、機器レベルでは、フォールトトレランスと冗長性の点でクラウドに利点があります。



鉄プロジェクトの投資回収は、年間の平均的な雲の価格です。

あなたはここにいる

この時点で、強制移動を終了しました。ご覧のように、私たちはあまり経済的な選択肢を持っていなかったため、何らかの理由で我慢しなければならないものを常にロードしました。これにより、負荷が不均一になるという奇妙な状況が発生しました。いずれかのセグメント（およびKrokのデータセンターのあるセグメントがボトルネックの2つのNexusに保持されている）の障害は、ユーザーエクスペリエンスの損失です。つまり、サイトは保持されますが、アクセシビリティには明らかな困難があります。



データセンター全体でMTSに障害が発生しました。他の2つがありました。定期的に、雲が落ちたり、クラウドコントローラーや、ある種の複雑なネットワークの問題が発生した。つまり、データセンターは時々失われます。はい、しばらくの間ですが、それでも不快です。ある時点で、データセンターが衰退しているのは当然のことと考えられていました。



データセンターレベルのフォールトトレランスを採用することにしました。



これで、5つのデータセンターの1つに障害が発生した場合、就寝できなくなります。しかし、クロックの肩を失うと、非常に深刻なドローダウンが発生します。そして、データセンターの弾力性のプロジェクトが生まれました。目標はこれです。DCが停止した場合、ネットワークが停止する前に、または機器が停止した場合、サイトは手動の介入なしに機能する必要があります。さらに、事故後、私たちは適切に回復する必要があります。

落とし穴は何ですか

今：





する必要があります：





今：





する必要があります：





Elasticは1つのノードの損失に耐性があります。





MySQLデータベース（多くの小さなデータベース）は管理が困難です。







バランシングを行った私の同僚は、これについてより詳細に書きます。これを掛ける前に、マスターを失った場合は、手でリザーブに行き、そこにフラグr / o = 0を入れ、すべてのレプリカをansibleでこの新しいマスターに再構築し、メインガーランドに2つ以上存在することが重要です。数十、アプリケーション構成を変更し、構成をロールアウトして更新を待ちます。これで、アプリケーションは、LVSバランサーを確認する1つのエニーキャストIPをウォークスルーします。定数設定は変更されません。オーケストレーター上のすべての基本トポロジー。



現在、ダークオプティクスはデータセンター間で拡張されているため、ローカル内のリング内の任意のリソースにアクセスできます。データセンター間の応答時間とプラスまたはマイナスの内側の時間は同じです。これは、ジオクラスターを構築している他の企業との重要な違いです。私たちはハードウェアとネットワークに強く結びついており、データセンター内でリクエストをローカライズしようとはしていません。一方で、これはクールですが、もう一方は、ヨーロッパや中国に行きたい場合、暗い光学系を引き出すことはありません。



これは、ほとんどすべて、主にデータベースをリバランスすることを意味します。多くのスキームがあり、アクティブマスターが読み取りと書き込みの両方の負荷全体を保持し、その隣に高速切り替え用の同期レプリカがあります（2つを同時に書き込むことはありませんが、複製します。それ以外の場合、うまく機能しません）。メインデータベースは1つのデータセンターにあり、レプリカは別のデータセンターにあります。それでも、部分的なコピーは、個々のアプリケーションの3番目にある場合があります。季節にもよりますが、このような例は10から15あります。 Orchestratorは、データセンターと3つのデータセンター間の拡張クラスターです。ここでは、このすべての音楽がどのように再生されるかを説明する力があるときに、より詳細に説明します。



アプリケーションについて詳しく調べる必要があります。これは今でも必要です。接続が切断された場合に、古い接続を消して新しい接続を開くことが正しい場合があります。ただし、プロセスが終了するまで、ループ内ですでに失われた接続で要求が繰り返される場合があります。つかまえられた最後のものは王冠のための仕事でした、列車についてのリマインダーは書かれていませんでした。



一般に、まだやることはありますが、計画は明確です。