2番目のDCのClodoセグメントとエラー処理

先週、私たちは商業運転で2番目のClodoクラウドセグメントを開始しました-Kurchatov Instituteの領域にあるKIAEHOUSE データセンターで



私たちは長い間テストし、デバッグしました。 2番目のセグメントに取り組んだときに私たちが設定した主なタスクは、「間違いに取り組む」ことです。私たちのハブログの読者の皆さん、私たちの投稿で私たちに思い出させるのに疲れないイベントにつながった欠点を取り除くことです。



ご存知のように、とにかく人的要因がなければ、事故やダウンタイムはありません。 人々は、どれほど専門的であっても、間違いを犯しがちです。 そのため、人的要因を最小限に抑え、クラウドライフのすべてのプロセスを自動化しようとしました。 さらに、安定性に関連する多くのタスクを設定しました。





クラウドの非人間化の主な要塞はシェフでした。これは、Habréで繰り返し説明されています。 Chefは、ソフトウェアアーキテクチャの再現性を担当する構成管理ツールです。 Chefには次のエンティティがあります。



Ohaiは構成の操作に使用され、Knifeは Chef Server APIとの対話に使用されます。

クラスターの読み込みシーケンスは次のとおりです。

  1. クラスターコントローラーで、Chef Soloが起動します。 彼には1つのタスクがあります-Chef Serverのインストールと構成です。
  2. ハードウェアノードは、Chef SoloがインストールされたDebian Liveイメージから起動します。 Chef Soloは、Chef Clientを構成し、ノードに役割を割り当てます(これには、ストレージノード、XENノード、リレー、Webサーバーを使用できます)。
  3. Chef Serverと通信するChef Clientは、その役割に合わせて機器ノードを構成します。


ストレージノード、Webサーバー、およびデータベースはクラスター化されています。 CoroSync通信層を備えたPacemakerは、クラスターリソースマネージャーとして使用されます。



別の単語は、 コントロールパネルに値します。 外部からの大きな変更に加えて、パネルはそのデバイスを根本的に変更しました。 これでAPIのクライアントになりました。 物理的には、各DCのAPIサーバーのセット(KIAEHOUSEの場合はkh.clodo.ru、「Oversan-Mercury」の場合はoversun.clodo.ru)と、DNS Round Robinの背後に隠されたapi.clodo.ruが別々にあります。 パネルはAPIクライアントであり、パネルからのすべてのサーバーおよびストレージ管理はAPIを介して行われます。 パネルは、このデータセンターのAPIを介してDCにあるサーバーと通信します。 DC間の接続が失われた場合、パネルは引き続き機能します。 1つのデータセンターで非常に大きな事故が発生した場合、2番目のデータセンターのマシンを以前と同様に制御できます。



現在、すべてのノードの監視のやり直しに忙しくしています。 すぐに、まったく新しい監視システムが導入されます。 現在、 Icingaを慎重に研究しています 。 これは非常に興味深いツールですが、残念ながら、まだHabréでカバーされていません。 監視には多くの重大なタスクが伴います。 アラートの精度に特に注意を払います。複数のシステムが結び付けられているノードで障害が発生した場合、障害のあるノードに関するアラートを受信し、他のアラートにownれたくないようにします。 さらに、監視はDC間の接続とは独立して機能し、クラスター化され、クラスターのノード間で負荷を分散でき、それ自体を非常によく監視する必要があります。



もちろん、さらに多くの変更がありますが、簡単な説明ですべてをカバーすることはできません。 2つのDCのセグメントを使用してフォールトトレラントソリューションを構築するために、バランサーレンタルサービスを追加する必要があります。 ただし、2番目のデータセンターのセグメントの試運転では、エラーに関する作業の重要な部分を行ったようです。 それまでの間、Habrの視聴者に、次の記事で詳しく説明する内容を選択してもらいたいと思います。 調査は次の投稿にあります。



重要なPS更新されたClodoをテストする場合は、info @ clodo.ruまでご連絡ください。 いくつか質問をした後、プロモーションコードまたはその他の適切なテスト条件を提供します。



All Articles