例としてCFEngineを使用する集中構成管理システムで数千のサーバーを配置しない方法

こんにちは、Habr！ 私の名前はDmitry Samsonovです。私はOdnoklassnikiの主要なシステム管理者として働いています。 私の中核能力は、Zabbix、CFEngine、およびLinux Optimizationです。 8,000以上のサーバーと200のアプリケーションがあり、さまざまな構成で700の異なるクラスターを形成しています。 この記事のトピックは、タイトルで徹底的に説明されています。

すぐに予約したい：

• OdnoklassnikiでのCFEngineの実装に参加したため、偏見が生じます。
• CFEngineのみのバージョン3.3-3.4を使用しました。
• CFEngineに幻想はありません。CFEngineは重要なプレーヤーですが、マーケットリーダーやその部外者ではありません。 この記事では、CFEngineを他のシステムと比較しません。
• 構成システムのうち、CFEngineとAnsibleのみを使用した経験があります。

クラシック構成ツール

最初に、使い慣れている古典的なシステムについて話しましょう。ssh、scp、mstsc、winexe-これらはすべて優れていますが、多数のサーバーの構成と管理には適していません。

プロジェクトに数十個以上のサーバーがある場合、ユーティリティdssh-command + dscp + dwinexe-commandでシェルを作成しました。最初はd-という文字が付いています。 彼らは同じことをすることができますが、同時に多数のサーバーで。

私たちの武器のもう1つのツールは、オペレーティングシステムのイメージです。 OSの構成を変更する必要がある場合は、運用中にdsshを実行し、新しいサーバーがこの構成をすぐに受信できるようにオペレーティングシステムのイメージを変更し、作業が完了したと見なしました。

まず、dsshコマンドユーティリティについて説明します。最初は完全に保護が含まれていなかったためです。

# cqn feeds-portlet-cdb | dssh-command -t 300 "date"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cqnは、CMDBからサーバーのリストを取得できるCLIコマンドです。 リストを取得し、標準のdssh-command



入力に渡して、これらのサーバーでdate



コマンドを実行するように依頼します。 -t 300



演算子は、実行中のコマンドとそれによって生成されたすべてのコマンドの両方が強制終了されるタイムアウトです。

なぜこれが必要なのですか？ おもしろい事件がありました。サーバーは動作し、動作しました。 -アプリケーションはそれに落ちました。 彼らは調査を始めました：この時点では、システム管理者は誰もサーバーとやり取りしていませんでしたが、接続が行われる前に、管理者はパラメーターなしでlsof



コマンドを起動しました。この場合、すべてのファイル記述子、つまり接続、ファイルなど。 さらに、実行中のアプリケーションの1つは膨大な数のスレッドを必要とし、多くの接続を開きました。 その結果、1つのlsof



チームが大量のメモリを消費し、その後OOM Killerが起動して全員を殺しました。

次に、コマンドの入力を確認する必要があります。 これらのツールのほとんどは、通常「はい/いいえ」のみを要求し、多くの場合、「はい」がデフォルトの選択肢です。 したがって、実際には、そのような保護は問題から私たちを救いません。 ただし、ここでは、確認として、数学演算の正しい結果を入力する必要があります。

 How much is 5 + 8 =
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コマンドラインで書いたとおりのことを本当にやりたいのなら、もう一度考える機会があります。 さらに、この計算機は1回ではなく、サーバーのボリュームが2倍になるたびに表示されます。

正解を入力すると、コマンドの実行が開始されます。

 Correct srvd1352:O:0:Fri Oct 14 13:17:52 MSK 2016 Executing: "date"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、すべてのサーバーで同時に実行されるわけでもありません。 最初に。 チームが間違っている可能性があるという事実。 これがonelinerの場合、間違いを犯すのは非常に簡単です。そのため、必要なものがコマンドラインに正確に入力され、期待される結果が得られることを1つのサーバーで確認してください。

次に、1つのデータセンターでコマンドが実行されます。 私たちの生産はすべていくつかのデータセンターにあり、それらはすべて互いに独立しています。 1つのデータセンターで数千のサーバーを失う可能性があり、ユーザーはこれに気付かないでしょう。

それにもかかわらず、誰もDC全体を失いたくない。 これを回避するために、前述の保護メカニズムに加えて、コマンドは最大50台のサーバーで同時に実行されます。

次に、すべてのサーバーがカバーされるまで、ユーザーは次のDCに進むかどうかなどを尋ねられます。 最後に、実行ログ、標準出力、標準エラー、終了ステータスなどを確認できます。

 Do you want to execute the command on servers in DL? [Yes/No]: Yes srvd1353:O:0:Fri Oct 14 13:17:53 MSK 2016 Executing: "date" Do you want to execute the command on servers in M100? [Yes/No]: Yes srve1993:O:0:Fri Oct 14 13:17:54 MSK 2016 srve2765:O:0:Fri Oct 14 13:17:54 MSK 2016 ... Full output saved in /tmp/dsshFullOutput_29606_2016-10-14_13-17.log file.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これはすべて、サーバーが正しく構成されていることを保証するものではありません。 最も一般的な例：サーバーは、再起動するだけで現在オフになっています-または、管理者が不良メモリやディスクを変更します。 これらの変更がサーバーに届かない理由は百万通りあります。 これを防ぐために、構成管理システムが考案されました。

システム選択

2012年に、これらのシステムのいずれかを実装する時期であると判断し、最初に基準のリストを作成しました。

• CMDB統合
• パッケージのインストール。
• ファイルの操作（コピー/編集/属性）;
• ファイル制御（コンテンツ/属性）;
• プロセスおよびサービス管理。
• ポリシー/レシピ/マニフェストの手動起動;
• バージョン管理、変更ログ、レポート。
• スケーリング、冗長性。
• LinuxおよびWindowsのサポート。
• CMが動作していないサーバーを確認します。

しかし、結果として、3つの主要な基準のみを選択しました。

最初はパフォーマンスです。 3,000台のサーバーにサービスを提供するCFEngineハブの負荷のグラフを次に示します。

1つのサーバーで数万人のクライアントに簡単にサービスを提供できます。 すべてはメモリと同じです。

次の基準は成熟度です。 これは、最新の構成管理ツールの出現に対する規模です。

ご覧のとおり、CFEngineは現在のすべての既存システムより少なくとも10年以上古いため、その機能と信頼性にある程度の自信があります。 ちなみに、PuppetとChefの2つの人気のある製品は次のように表示されます。Puppetの開発者はCFEngineを使用しましたが、好まなかったため、Puppetを作成しました。 別の開発者はPuppetを好まなかったため、Chefを作成しました。

最後の基準は人気です。 CFEngineはロシアではまったく普及していませんが、NASA、IBM、LinkedInなどの大企業で使用されています。 Googleトレンドの履歴データを見てみましょう。

CFEngineは非常に人気があり、長い間、他の構成管理システムがまだあまり一般的ではなかった市場リーダーであり続けました。 2012年、CFEngineはすべての要件を最もよく満たしました。 多くの人は、その機能、ロジック、および言語構成の特異性のためにこのツールを悪魔化します。 ただし、非常に使いやすい状態にすることができます。

OdnoklassnikiのCFEngine

以下に、本番環境で一般的なアプリケーションをセットアップするためのポリシーの例を示します。

 "app_ok_feed" or => {"cmdb_group_feeds_proxy", “cmdb_group_feeds_cache}; ... bundle agent app_ok_feed { vars: "application" string => "ok-feed"; methods: "app_ok" usebundle => app_ok("$(application)"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポリシーの名前はapp_ok_feed



、サーバーの2つのグループ（ feeds_proxy



とfeeds_cache



）に適用され、アプリケーションの名前と起動されるapp_ok



メソッドがあります。 CFEngineの構文がわからなくても、理解するのに困難はありません。

次の抽象化レベルにapp_ok



ましょうapp_ok



メソッドのポリシーに直接。

 bundle agent app_ok(application) { vars: "file[/ok/bin/$(application)][policy]" string => "copy"; "file[/ok/bin/$(application)][mode]" string => "0755"; "file[/ok/conf/$(application).conf][policy]" string => "copy"; "file[/root/ok/ok.properties][policy]" string => "edit"; "file[/root/ok/ok.properties][suffix]" string => "$(application)"; "file[/root/ok/ok.properties][type]" string => "file"; methods: "files" usebundle => files_manage("$(this.bundle).file"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、アプリケーションの名前を取得し、いくつかの構成をコピーし、それらに必要なアクセス許可を設定して、次の抽象化レベルにfiles_manage



ますfiles_manage



メソッドを呼び出します。 つまり、CFEngineを使用すると、抽象化レベルを簡単に作成できます。

いくつかの非常に短い例：

• ユーザーの追加： "user[git][policy]" string => "add";
  
  
  
  
• サービスを開始します： "service[mysql][policy]" string => "start";
  
  
  
  
• クラウンを追加： "cron[do_well][cron]" string => "* * * * * do_well";
  
  
  
  
• パッケージをインストールします： "package[rsyslog][policy]" string => "add";
  
  
  
  

ポリシーの種類の分布：

約1500個あり、最大のポリシーは27 Kbです。奇妙なことに、これはZabbixサーバー構成ポリシーです。 絶対にすべての側面を説明します。ベアサーバーを使用してポリシーを実行すると、データベースとフロントエンドに必要なすべてのパッチが構成されます。

構成システムがしばしば構成しない特定の事柄のいくつかの例：

• IPルート
• HW RAIDキャッシュエントリ
• SELinux
• IPMI SOL;
• カーネルモジュール。
• RSS / RPS / RFS。

CFEngineを使用してすべて自動化しています。 必要なモードとサーバーを指定するだけで十分です。残りはシステムが行います。

短所

ただし、CFEngineには欠点があります。 まず第一に、これは高いエントリーしきい値です。 新入社員とそれらを訓練する人にとっての最大の痛みは、すべての内部ロジックの説明です。 もちろん、高レベルの抽象化があります。 それにもかかわらず、このツールを使用したいシステム管理者にとって、このツールが内部でどのように機能するかを理解することは重要です。

次の問題はCFEngineが競合他社よりはるかに遅れているということです。 私は幻想を抱いておらず、現代のシステムの能力を知っています。CFEngineはそれらからはほど遠いです。

CFEngineには機能を拡張する機会はありません 。 Cで記述されています。他の一般的なシステムには、基本的にPythonなどの単純な言語で記述されたプラグインがあります。

悪いパターン 。 それらは機能が弱く、特定のことを実行できないため、いくつかの異なるファイルを作成する必要があります。

4月4日

4月4日に注目すべきことは何ですか？ これはWeb開発者の日です。 しかし、それだけではありません。 2013年4月4日、すべてのユーザーがOdnoklassnikiプロジェクトを利用できなくなり、3日間修正を試みました。 問題は複雑で、すべてのサーバーがユーザーとシステム管理者にアクセスできなくなり、再起動は役に立ちませんでした。 このケースは、ダウンタイムの世界史に入りました。 詳細については、「 2013年に私たちに衝撃を与えた3日間 」の記事をご覧ください 。

これは回避できたでしょうか？ 当然、保護装置は私たちのために働いた：

• 構文チェック;
• テスト環境。
• 復習
• 監視

それにもかかわらず、悪魔は詳細にあります。 同じレビューは存在しましたが、オプションでした。 すべてを壊したコミットについては、レビューを経て、少なくとも2人の管理者がそれを調べましたが、保存されませんでした。 コミットでは、いくつかの文字が設定に追加され、悲劇的な状況が発生しました。あるシステムのバグが別のシステムのバグと重なり、すべてが崩壊しました。

CFEngineにより数千台のサーバーが機能しなくなったとき、最初に停止しました。 システム管理者が何らかの構成システムを使用するかどうか、そしてもしそうなら、どのように使用するかについて、座って非常に真剣に考えなければなりませんでした。 さらに、可能な限り人的要因を除外する必要があり、災害の再発の可能性を物理的に制限していました。

まず第一に、私たちは最後にCFEngineを離れたことに注意したいと思います。 さらに、これまで各サーバーで5分ごとに1回実行されていました 。 構成管理システムは、何よりもまずサーバーが希望どおりに構成されていることを確認するため、これは重要です。 そして、これはすべてのサーバーに当てはまります。 彼らは私たちが望む構成を持っています、すべてが正確に行われます、私はこれをチェックする必要はありません-CFEngineまたは他の構成管理システムが私のためにこれを行います。

CFEngineはJavaアプリケーションの展開には一切関与していないことに注意してください。 別のsamopisnayaシステムがある展開の準備をする可能性が高くなります。 サーバーをロールアウトし、CFEngineにより準備完了状態になり、メインのJavaアプリケーションを別のシステムに簡単にインストールできます。

この状況が再び発生するのを防ぐために、どのような対策を講じましたか？

保護の最初のレベルはgitです。 そこにはフックがあり、CFEngineポリシーのすべてのソースはgitにあります。 gitフックでは、構文がチェックされ、スタイルが自動的に調整され、コミットメッセージがオートコンプリートされてチェックされます。 後者は完全にセキュリティに関連しているわけではありませんが、問題が発生した場合は、タスク番号またはデータセンターの名前によってそれらに関連するすべてのコミットをすばやく見つけることができます。 コミットを作成するとき、管理者はチケット番号とコメント自体を最初に書き込み、フックはどのファイルが変更されたかを分析し、影響を受ける環境をメッセージに追加します。 その結果、典型的なコミットメッセージは「タスク番号：[環境のリスト]コメント」のようになります。 例：

 ADMODKL-54581: [D,E,G,K,P] add some cloud-minion-ec to stable
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の保護ステップは、テスト環境での検証です 。 テスト環境はいくつかの部分で構成されています。 最初の部分は不安定であり、これらは誰でも使用できる仮想マシンであり、可能な限りそれらを破壊することができます。 5分ごとに更新されます。 次にテスト環境が登場します-物理サーバーでの検証（物理サーバーの一部のポリシーは異なる方法で実装されます）。 また、仮想マシンとは異なり、CMDBに物理サーバーがありますが、ポリシーも異なる方法で適用できます。 それでも、このレイヤーは完全に失われる可能性があり、5分ごとに更新されます。

次の保護は、自動化された負荷制御を使用して、運用サーバーの一部をチェックすることです 。 これらは、実際のユーザーが座っている実際に稼働しているサーバー、データベース、フロントエンドなどです。 フォールトトレラントである場合、運用環境にインストールする新しいクラスターごとに1つのサーバーを取得し、安定した環境に追加します。 したがって、絶対にすべてのタイプのハードウェア（RAIDコントローラー、マザーボード、ネットワークカードなど）、すべてのタイプのアプリケーション、それらのさまざまな構成があります。 私たちの生産で可能なすべて。

なぜなら クラスターから1つのサーバーのみが安定します。このサーバーがユーザーに影響を与えずに失われる可能性がある場合にのみ、安定した環境ポリシーの致命的なエラーがユーザーに影響を与えない場合のみ、ユーザーは中断せずにポータルを使用し続けます。

安定版では、すべてのシステム管理者がコミットでき、それを破ることができますが、ここではポリシーは5分ではなく1時間で更新されます。 それでも、もう一度100台のサーバーを修復したいという人はいないので、1時間以内にサーバーをスムーズに更新します。

本番サーバーの場合も、負荷は自動的に制御されます。 当然、すべてを監視していますが、特にこれらのサーバーについては、それらに異常が発生しないように少なくとも2時間監視します。 ありふれたメモリリークが発生している可能性があります。 これをすぐに実稼働環境に提供すると、結果が最も悲惨なものになる可能性があります。 重大な変更により、ポリシーは安定した日に保たれます。

次の防御メカニズムはレビューです。 スタイル（gitフックによって自動的に修正されなかったもの）、メソッドの最新バージョンの使用、コードの「妥当性」をチェックします。

しかし、政治家が生産に入る前に、レビュー担当者は、以前のすべての環境でエラーが発生しないこと、負荷の異常がないこと、少なくとも2時間が経過していることを確認する必要があります。 その後、レビューアが本番にコミットを送信します。

当然、迅速に解決する必要がある問題があり、このために保護メカニズムを回避できます。 これも想定しました。 たとえば、5台のサーバーですばやくコミットする必要がある場合は、5台のサーバーに移動して、手動で更新できます。 ただし、すべてのサーバーでこれを行うわけではありません。 多数のサーバーを操作するために、独自の保護メカニズムを備えた特別なツールがあります。

最初は、CFEngineを実装した3人の管理者のみがレビューに従事し、それらについて最高の知識を持ち、最も経験が豊富でした。

次に、2レベルのレビューを導入しました。 すべての管理者が閲覧できます。 これにより作業が大幅に加速し、数人を待つ必要はありませんでした。 あなたの隣人に行くことは可能でした、彼は事前教育をしていましたが、上級システム管理者はすでに予想を実行していました。

現在、すべての管理者が十分なレベルの能力を獲得しており、会社で長い間働いていたすべての人の再審査をキャンセルしました。

そして最後の保護レベルは、生産政策の広がりに対する保護です。 これらはダーツと呼ばれます。

文字は、DCの略です。 データラインのデータセンターは文字Dで書かれており、1日3回更新されます。9から10、13から14、17から18です。データセンターは独立しているため、このスキームのおかげで問題に気づくことができます。 DCによってポリシーが更新され、DCが低下し始めた場合、これは時間内に表示され、残りのDCは影響を受けません。 そして、私たちが丸1時間、つまり生産全体が落ちる3時間前に気づかなかったとしても。

「グリーン」なデータラインが午前9時に更新を開始すると言っても、サーバーの100％がすぐに新しいポリシーをポンプアウトしたという意味ではありません。 これは徐々に行われます。 一度にDC全体を失いたくはありません。したがって、ポリシーは限られた数のサーバーで同時に更新されます。これは標準のCFEngine機能-splayクラスです。 手は何もする必要がなく、すべてが自動化されています。

さらに保護されるのは、ポリシーが8から20にのみ更新されることです。夜間に誰も驚きを望みません。

エラーがデータライン全体に広がる場合、手順は問題の深刻度によって異なります。 ここで今すぐ修正する必要がある場合は、すでにおなじみのdsshまたは通常のsshを使用して、まだ介入できます。 CFEngineとの競合が何であれ、個々のポリシーまたは個々のファイルに対してもCFEngineを一時的に無効にするメカニズムがあります。 これらの一時的な変更を忘れても機能しません。 タイムアウト（3日）後、CFEngineにないすべての変更はロールバックされます。

多数のサーバーで問題が発生した場合、状況の重大度に応じて、ここで異なるアクションを実行できます。 一般的に、私たちは手動で何もしません。 問題が待機できる場合は、標準手順に従ってください：コミット、安定、レビュー-4時間以内に修正がこれらのサーバーにクロールされます。 すべてが悪く、サービスに顕著な問題がある場合は、コミットをすぐにロールバックします。

そのため、ポリシーを準備して本番環境に送信する場合、5つのレベルの保護があります。 しかし、それだけでは不十分だと判断しました。 悪い政治がまだ生産に侵入している場合はどうすればよいですか？

プランBがあります。これもポリシーを備えた別のgitリポジトリですが、それらは非常にシンプルで、非常に少数であり、そこに変更を加えることはほとんどありません。 すべてが壊れている場合、CFEngineは代替のポリシーセットに切り替えます。これにより、まず、CFEngine自体の機能をメインツールとして維持できます。 そして、切り替え後、より深刻な問題を修正するために使用できます。

しかし、これでさえ十分ではないようでしたので、数十秒間、実稼働中のCFEngineをすばやく停止できる小さなスクリプトを作成しました。 2013年以来、このツールを使用したことはありません！ しかし、定期的にパフォーマンスを確認してください

変更の自動ロールバックがないのはなぜですか？ CFEngineにはトランザクションやログがないためです。 当然、構成はバックアップすることができ、それを行います。 しかし、この問題につながった仕事の全量を知ることはできません。 たぶんそれは設定だった。 多分パッケージの更新。 サービスを再起動する可能性があります。 たぶん、アクションまたはそれらのシーケンスの組み合わせ。 , , . , .

, , , . , , , : , , , , .

, . , , : 50, 100, 200, 400 . .

— , . :

• ,
• - ,

. production, , production . — , , .

Highload++ 2016 .