数百のサーバーでインフラストラクチャを管理し、問題を回避する方法:King Serversエンジニアからの5つのヒント





ITインフラストラクチャの構築についてHabréのブログで多くのことを書いています。たとえば、 ロシアアメリカのデータセンターを選択する際の問題を明らかにしています。 現在、キングサーバー内では数百の物理サーバーと数千の仮想サーバーが動作しています。 今日、エンジニアはこの規模のインフラストラクチャを管理するためのヒントを共有しています。



自動化は非常に重要です。



この規模のインフラストラクチャを管理するための成功の最も重要な要素の1つは、十分に確立された監視です。 このような多数のサーバーを手動で監視することは、多くのエンジニアがいる場合でも物理的に非現実的であるため、自動化を使用する必要があります。 システム自体が考えられる問題を見つけて、それらについて通知する必要があります。 このような監視を可能な限り効果的にするには、考えられるすべての障害点を事前に予測する必要があります。 問題は、自動モードの初期段階で特定する必要があります。これにより、エンジニアは、通常モードで必要なアクションを実行し、既にドロップされたサービスを復元する時間がありません。



また、日常的な活動を可能な限り自動化することも重要です。 10台のサーバーにサポートキーをインストールすることは1つのタスクであり、300をカバーする必要がある場合はまったく異なります。



インフラストラクチャは、時間とともにサイズが大きくなる傾向があることを理解することが重要です。 ただし、通常、会社のエンジニアの数は対応するペースで増加しません。 問題を回避するには、現時点で手に対処できると思われる場合でも、すぐに自動化を実装する必要があります。 週に一度アクションが繰り返される場合、それを自動化する必要がないと思われる場合、ミスは非常に一般的です。 実際、スクリプトの作成に費やした時間は、繰り返しアクションを実行するのにかかる時間を短縮することにより、近い将来に報われるでしょう。 また、このアプローチにより、時間の経過とともに、インフラストラクチャ専用のスクリプトのデータベースが構築され、新しいスクリプトで既製のコードフラグメントを使用できるようになり、時間も節約されます。



そして、もちろん、複数のエンジニアがすべての自動生成された通知を受信する必要があります。 数百のサービスを効果的に管理する高度な自動化を使用しても、1人または2人のエンジニアからなる非常に小さなチームではできません。 適切なオプションは、オンラインでエンジニアの1人が引き続き存在することです。 私たちの経験では、これには最低4人のエンジニアが必要です。



重要な状況での予約とバックアップの保存



大規模なインフラストラクチャの場合、障害が発生すると多数のユーザーが被害を受けるため、冗長性はさらに重要になります。 予約する価値があります:





定期的なバックアップとテスト、およびバックアップの展開も、インフラストラクチャを管理する上で不可欠な要素です。 大量のデータをバックアップし、頻繁にバックアップを作成する必要がある場合、バックアップが保存されているサーバーのパフォーマンスを監視することを忘れないことが重要です。 すでにデータが多すぎるため、バックアップにはまだ時間がなく、新しいデータがすでに開始されていることが判明する場合があります。



ドキュメントとログの作成



プロジェクトが複数のエンジニアによってサポートされている場合、インフラストラクチャの近代化に合わせて作業プロセスを文書化することが非常に重要です。 最初から、独自の知識ベースを作成し、新しいオプションの導入とともに、それらの操作に関するドキュメントを作成する必要があります。 プロジェクトをサポートするすべての人が、プロジェクトの機能と仕組みをすでに知っているとしても。 拡大するエンジニアチームにより、適切に記述されたドキュメントは、プロジェクトに新しいチームメンバーを紹介するプロセスを大幅にスピードアップするのに役立ちます。



スクリプト作成も開発であることを忘れないでください。スクリプトで作業する場合、問題が発生した場合に以前のバージョンにすばやくロールバックできるように、数人がバージョン管理システムを取得して変更を追跡する必要があります。



複数の人が同じタスクに取り組んでいる場合、何が行われたかについての情報を伝えることが重要です。 作業の詳細なログを自動モードで維持し、中央サーバーに保存する時間を大幅に短縮します。 これにより、タスクの別の人への転送が簡単になります(実行されたアクションを指定する必要はありません。すべてがログファイルに記録されます)。



データセンターのエンジニアの応答時間を分析することが重要です



適切な最新のデータセンターはすべて、リモートハンドサービスを提供します。このサービスでは、問題が発生した場合、サーバーの所有者がサイトのエンジニアに機器で必要なアクションを実行するよう依頼できます。 しかし、常に最後ではなく、サイトは質的にそれをレンダリングします。 多くの理由がありますが、最も頻繁に起こるのは専門家の高い作業負荷、またはサイトにエンジニアがいないことです(米国のデータセンターの1つがそのようなオプションを提供してくれました-勤務時間中にエンジニアを辞めます)。また、問題は労働時間中だけでなく発生する場合があります。



したがって、インフラストラクチャ全体を1つのデータセンターにすぐに移行することは避けてください。段階的に移行を実行することをお勧めします。



また、機器を移動し、すべてのケーブルをきちんと敷設した後、リモートハンドサービスの一部として数年と数十件の助けを求めた後、写真は次のようになります。







また、作業中に、ケーブルが豊富であるために、1台のサーバーを他のサーバーの動作を中断せずにラックから取り外すことができない場合、問題が発生し始めます。 ラックの状態を定期的に確認し、データセンターのスタッフに写真を撮ってもらうことが重要です。



節約のために努力する必要はなく、よりよく注意深く実験する



機器の特性を慎重に研究する必要があります-これにより、起こりうる問題をより正確に予測できます。 たとえば、SSDの場合、分析に費やす少しの余分な時間が鉄を獲得する可能性があり、それは急いで購入したよりもはるかに長く生きます。



そのようなアプローチでは、今ここで保存できないという事実に備えておく必要があります。 長期的には、鉄を節約すると損失が発生します。低価格は常に低い信頼性によって補われ、結果として鉄の修理と交換は多くの場合、より長寿命の高価な機器を購入するよりも高価です。



私たちのプロジェクトでは、長年SuperMicro製品を使用してきました-これらのサーバーに重大な原因のない障害はありませんでした。 また、それほど前ではないが、彼らはDellの機器を非常に慎重に使用し始めました。 この会社の製品は非常に高い評価を得ていますが、新しい鉄で作業量を劇的に増やすことは常にリスクがあるため、徐々に動いています。



コンポーネントに関しては、ここでの実験も不適切です-偏執狂的であり、信頼できるサプライヤーのみを信頼する方がよいでしょう。 同じように、サーバー内のデスクトップコンピューターのコンポーネントを使用することも、カテゴリ的には必要ありません。これらは、根本的に異なる負荷向けに設計されたまったく異なるクラスのデバイスです。







特に外部の顧客がインフラストラクチャを使用する場合、これは何の役にも立ちません-ホスティング業界では、ユーザーがビジネス用に仮想サーバーを購入することは珍しくありませんが、バックアップを忘れるか、展開をテストしません(これは小規模企業が管理者を節約する方法です)。 同時に物理サーバーもデスクトップコンポーネントの半分で組み立てられた場合、すぐにデータが完全に失われるという障害が発生します。これにより、他の人のビジネスが停止する可能性があります。 これは許可されるべきではありません。



King Serversからのより便利なリンクと資料:






All Articles