5年は中間結果を要約するための特徴的な時期です。そこで、5年間で驚くほど興味深い開発パスを経てきたインフラの開発についてお話しすることにしました。私たちが実施した量的変化は質的変化に変わりました。今では、インフラストラクチャは過去10年の半ばに素晴らしいと思われたモードで動作できます。
PREMIERやMatchTVなど、信頼性と負荷に対する最も厳しい要件を持つ最も複雑なプロジェクトに作業を提供します。スポーツ放送や人気のTVシリーズのプレミアでは、テラビット/秒でトラフィックを返す必要があり、これを簡単に実装できます。そのような速度での作業は、長い間一般的になっています。そして5年前、私たちのシステムで作業する最も困難なプロジェクトはRutubeでした。これはそれ以来進化し、ワークロードを計画する際に考慮しなければならないボリュームとトラフィックを増加させました。
インフラストラクチャのハードウェアをどのように開発したか（「Rutube2009-2015：ハードウェアの歴史」）と、ビデオのアップロードを担当するシステムを開発した方法（「毎秒0から700ギガビット-ロシアで最大のビデオホスティングサイトの1つ」）について話しました。 「」）が、これらのテキストの作成から多くの時間が経過し、他の多くのソリューションが作成および実装されました。その結果、最新の要件を満たし、新しいタスクのために再構築するのに十分な柔軟性が得られます。
私たちは常にネットワークコアを開発しています。前回の記事で述べたように、2015年にシスコの機器に切り替えました。その後はすべて同じ10 / 40Gでしたが、明らかな理由で、数年後に既存のシャーシをアップグレードし、現在は25 / 100Gも積極的に使用しています。
100Gリンクは長い間贅沢ではなく（むしろ、それは私たちのセグメントでの時間の緊急の要件です）、希少性でもありません（ますます多くのオペレーターがそのような速度で接続を提供します）。ただし、10 / 40Gは引き続き関連性があります。これらのリンクを介して、オペレーターを少量のトラフィックで接続し続けます。現在、より容量の大きいポートを使用することは現実的ではありません。
私たちが作成したネットワークコアは、別の検討に値するものであり、少し後で別の記事のトピックになります。そこで、技術的な詳細を掘り下げ、それを作成する際のアクションのロジックを検討します。しかし、読者の皆様のご注意は無制限ではないため、インフラストラクチャをより概略的に描き続けます。
ビデオサービングサーバー急速に進化するため、私たちは多大な努力を払っています。以前は、それぞれ2つの10Gポートを備えた4〜5のネットワークカードを備えた2Uサーバーを主に使用していましたが、現在、ほとんどのトラフィックは1Uサーバーから送信され、それぞれ2つの25Gポートを備えた2〜3のカードがあります。 10Gと25Gのカードはコストがほぼ同じであり、より高速なソリューションを使用すると、10Gと25Gの両方を提供できます。その結果、明らかに節約できます。接続するサーバーコンポーネントとケーブルが少なくなり、コストが削減され（信頼性が高く）、コンポーネントが占めるラックスペースが少なくなります。フロアスペースの単位あたりに収容できるサーバーが増えるため、レンタルコストが削減されます。
しかし、もっと重要なのはスピードの向上です！今1Uで100G以上を与えることができます！そしてこれは、いくつかの大規模なロシアのプロジェクトが2Uで40Gのリターンを「達成」と呼ぶ状況の背景に反しています。私たちは彼らの問題を抱えているでしょう！
10Gでのみ機能するネットワークカードの生成は、引き続き使用していることに注意してください。この装置は安定して動作し、私たちに完全に馴染みがあるので、私たちはそれを捨てませんでしたが、それの新しいアプリケーションを見つけました。これらのコンポーネントをビデオストレージサーバーにインストールしましたが、1つまたは2つの1Gインターフェイスでは効果的な操作には明らかに不十分であり、ここでは10Gカードが適切であることが判明しました。
ストレージシステム成長します。過去5年間で、12ディスクドライブ（12x HDD 2U）から36ディスクドライブ（36x HDD 4U）に変更されました。一部の人々は、そのような容量の大きい「死骸」を使用することを恐れています。そのようなシャーシの1つに障害が発生した場合、パフォーマンス、さらには作業能力に脅威が及ぶ可能性があるためです。 -システム全体。しかし、これは私たちには起こりません。私たちは、地理的に分散したデータのコピーのレベルでバックアップを提供しました。シャーシをさまざまなデータセンターに分散し（合計3つ使用）、これにより、シャーシに障害が発生した場合とプラットフォームが落下した場合の両方で問題が発生することがなくなります。
もちろん、このアプローチによりハードウェアRAIDが冗長になり、これは放棄されました。冗長性を排除することで、システムの信頼性を高め、ソリューションを簡素化し、潜在的な障害点の1つを取り除きました。私たちのストレージシステムは「自作」であることを思い出してください。私たちはこれを完全に意図的に行い、結果は私たちにとって完全に満足のいくものでした。過去5年間で、
データセンターを数回変更しました。前回の記事の執筆以来、1つのデータセンター（DataLine）のみを変更したわけではなく、インフラストラクチャの開発に伴い、残りは交換が必要でした。サイト間のすべての転送が計画されました。
2年前、私たちはMMTS-9内に移動し、高品質の修理、優れた冷却システム、安定した電源、ほこりのない場所に移動しました。これは、すべての表面に厚い層があり、機器の内部も大量に詰まっています。質の高いサービスを選ぶ-そしてほこりのない！ -私たちの移動の理由になりました。
ほとんどの場合、「1回の移動は2回の火災に相当します」が、移行の問題は毎回異なります。今回、1つのデータセンター内を移動する際の主な問題は、光の相互接続によって「提供」されました。これは、通信事業者が単一の相互接続に結合することなく、床間の存在量を示します。交差点の更新と再ルーティングのプロセス（MMTS-9エンジニアが支援してくれた）は、おそらく移行の最も困難な段階でした。
2回目の移行は、1年前に行われ、2019年に、あまり良くないデータセンターからO2xygenに移行しました。移転の理由は上記の理由と同様でしたが、通信事業者にとって元のデータセンターの魅力がないという問題によって補完されました。多くのプロバイダーは、この時点まで独自に「追いつく」必要がありました。
13ラックをMMTS-9の高品質サイトに移行することで、この場所をオペレーター（2つのラックと「転送」オペレーター）として開発するだけでなく、主要な場所の1つとして使用することも可能になりました。これにより、あまり良くないデータセンターからの移行がいくらか簡素化されました。ほとんどの機器をそこから別のサイトに移動し、O2xygenが開発の役割を果たし、そこに機器を備えた5つのラックを送りました。
今日、O2xygenはすでに本格的なプラットフォームであり、必要なオペレーターが「来て」、新しいオペレーターが接続し続けています。オペレーターにとって、O2xygenは戦略的開発の観点からも魅力的でした。
私たちは間違いなく移動のメインフェーズを一晩で過ごし、MMTS-9内とO2xygenに移行するときは、このルールを順守しました。ラックの数に関係なく、「夜に移動する」というルールを厳守することを強調します。 20ラックを移動して一晩で行ったときも前例がありました。移行は非常に単純なプロセスであり、正確さと一貫性が必要ですが、準備プロセス、移動時、および新しい場所への展開時の両方で、いくつかのトリックがあります。興味があれば、移行について詳しくお話しする準備ができています。
結果私たちは5年間の開発計画が好きです。 3つのデータセンターにまたがる新しい復元力のあるインフラストラクチャの構築が完了しました。トラフィック配信の密度が劇的に向上しました。最近、2Uで40〜80Gで喜んだ場合、1Uで100Gを提供するのが普通です。今では、1テラビットのトラフィックが当たり前のように認識されています。柔軟でスケーラブルであることが判明したインフラストラクチャをさらに開発する準備ができています。
質問：読者の皆様、次のテキストで何をお伝えしますか？なぜ自家製のストレージシステムの構築を始めたのですか？ネットワークコアとその機能について？データセンター間の移行のコツと複雑さについて？コンポーネントを選択し、パラメータを微調整することにより、発行決定を最適化することについて？3つのデータセンターの構造で実装されているデータセンター内の複数の冗長性と水平方向のスケーラビリティのおかげで持続可能なソリューションを作成することについて？
著者：PetrVinogradov-Uma.Techのテクニカルディレクターハムスター