数個（5個程度）のボックスで実行されているアプリケーションがあります。ハードウェアはすべてのマシンで同一であり、ソフトウェアも理想的です。私はこれまで手作業でそれらを管理してきましたが、もうしたくありません（静的IPアドレス、必要なすべてのサービスの無効化、必要なパッケージのインストール...）。誰でも次のオプションの長所と短所のバランスをとることができますか？

1：すべてのボックスに個別にcentosをインストールし、chef / cfengine / puppetで構成を管理します。私はアプリケーションの1つを使用することを学ぶための言い訳を望んでいたので、これは良いでしょうが、これが実際に最良の解決策であるかどうかはわかりません。

2：1つのボックスを完璧にしてイメージします。PXEを介してイメージを提供し、変更を加えたいときはいつでも、新しいイメージからボックスをリブートできます。通常、クラスタ担当者は、/ etc / sysconfig / network-scripts / ifcfg *ファイルにMACアドレスがあるなどのことをどのように処理しますか？infinibandも使用します。また、hwaddrが間違っている場合は開始を拒否します。これらは起動時に正しく生成できますか？

私はPXEソリューションに傾いていますが、muninまたはnagiosでの監視はこれにより少し複雑になると思います。このタイプの問題を経験した人はいますか？

すべてのサーバーにはSSDが搭載されており、高速で強力です。

ありがとう、マット。

あなたのクラスターは私のようなOLTPクラスターよりもHPCクラスターのように聞こえますが、私が使用しているセットアップはあなたにとってもうまくいくと思います。私はそれを「mpdehaan trifecta」と呼びます。これは、関連する3つのツールを作成または管理する人のircnickであるためです。

1.）基本ビルドプロビジョニング用のCobbler。Cobblerは、キックスタート、pxe、yum-repo、dhcp、dnsなどのシステムの共通部分を目指したプロジェクトです。キックスタートのセットアップを実行する最も簡単な方法であり、必要に応じて他の機能に成長できます。

2.）構成管理用のPuppet。理想的には、Cobblerで構築されたホストは、起動時にパペットサーバーに電話をかけるのに十分なだけの非常に単純な構成です。その後、Puppetは構成設定を適用し、環境全体で永続的に一貫性を保ちます。

3.）のFuncアドホックコマンド並行して複数のマシンにため。たとえば、「コードの新しいsvnチェックアウトをデプロイし、Apacheを再起動します」。cluster-sshのようなサーバーのグループで同じbashコマンドを呼び出すためにfuncを使用するのは非常に簡単です。あなたが本当にそれに興味があれば、いくつかの本当にシンプルなpythonを使って独自のモジュールを書くことができます。

これらの3つのツールはすべて、freenodeのヘルプ用の優れたwikiとアクティブなircチャネルを備えています。

概要

いくつかの点で、ここに2つの質問があります。

• 標準サーバーを構築および保守するにはどうすればよいですか？
• 標準構成を維持し、後で変更するにはどうすればよいですか？

これらの2つのことを別々に扱って以下の答えを分けましたが、それらは非常に密接に関連しています。ここでは、変更管理などの関連するベストプラクティスではなく、テクノロジソリューションについて説明します。

これで質問の範囲がカバーされない場合は、明確にしてください。詳しく説明させていただきます。これは必要な基盤であり、適切に実行されている技術インフラストラクチャにとって重要です。

サーバーの構築

私はUNIXの世界の画像が好きではありません。これは、Windowsスタイルのアプローチです。一部のWindowsの人々でさえ、現在は標準ビルドのスクリプトに焦点を合わせているようです。

サテライトはRHELの世界でやや人気が高まっているようです。Spacewalkは、オープンソースの対応物です。これを使用するには、完全にRHELアプローチを購入する必要があります。これは、サーバー構築と構成管理の両方として機能します。

理想的には、必要なすべてのソフトウェアのために、ファイルサーバー上にローカルミラーとリポジトリを確立したいと思うでしょう。

まず、RHEL / CentOSのキックスタートなど、ディストリビューションビルドの自動化を活用します。キックスタートは、ニーズに応じてさまざまなベースラインになります。キックスタートビルドは、PXEサーバーから開始できます。

ビルドのより高度な部分、およびキックスタートファイルに適さないものについては、独自のカスタムスクリプトを作成できます。ただし、カスタムスクリプトではなく、puppetまたはcfengineが適切に機能する場合があります。カスタムスクリプトが最も柔軟で、単一のアプローチに限定されないことがわかりました。

独自のスクリプトを作成することを選択した場合、ユニバーサル構成のコアスクリプトをお勧めします。これは、セキュリティ構成、強化、およびすべてのビルドに適用されるものです。次に、サーバーの役割を確定する最終スクリプト。たとえば、Webサーバーまたはデータベースサーバー。

標準の維持

あなたが説明することは、構成の維持にも該当します。ビルドの標準、ソフトウェアの更新などはビルドに関連していますが、多くの点で異なります。

最も重要なサーバーロール用に独自のソースベースのビルドを作成するのではなく、システムパッケージに依存することを選択した場合、その多くはネイティブシステムユーティリティで維持できます。これはfor、サーバーリストに対してループを実行してyum -y update package。

構成管理では、ここでpuppet、cfengine、およびその他の構成管理ユーティリティが役立ちます。これらは非常に便利なユーティリティであり、独自のスクリプトを最初から記述することなく必要な基盤を提供します。

サーバーの構成標準を更新するときは、これを標準サーバービルドに埋め戻すことが重要です。

私は最近、$ WORKで集中化されたビルド/プロビジョニングおよび構成管理システムを展開する大きなプロジェクトを終了しました。CentOSを実行しています。

私が本当に気に入っているデザインは、シンプルで効果的なWeb UIを介してすべてを結び付けるカスタムPHPスクリプトを使用して、事実上ワンクリック（まあ、1つのWeb GUIページ）のビルドプロセスを提供します。

一般的な理論は次のとおりです。

1. 単一の統一された最小限のKickStartファイルからすべてのインストールを行います（まあ、1つはx86用、もう1つはx86-64用ですが、最小限のパッケージ選択で実質的に同一のファイルです）。
2. KickStat postinstallスクリプトはPuppetをブートストラップします。
3. Puppetは、すべてのノード/ホスト固有の構成、パッケージのインストールなどを適用します。

イメージは物事を行うためのUnix-yの方法ではないことに同意します。スクリプト化/自動化されたインストールと構成がそれほど単純ではないWindowsの世界により適しています。

Puppetを法案に合った他の構成管理システムに置き換えることができますが、たまたまPuppetの宣言的な性質と収束の概念が好きです。

このシステムには多くの利点があります。

• Puppetは、一般的な基本インストール以降のすべてを処理するため、必要なパッケージと構成はすべて1か所にまとめられています。
• Puppetマニフェストは、低レベルのドキュメントの追加ソースとして機能します。
• Puppetに固執している限り（つまり、ローカル設定を変更したり、Puppetにマージしたりしない限り）、マシンの複製を作成するのは簡単です。
• すべてのホストは共通のベースから構築されるため、ベース（KickStart）パッケージセットを使用してハードウェアまたはVMを事前インストールし、必要に応じてクラスを追加するだけで機能ノードに変換できます。
• Puppetでは、ホストを実稼働または開発用に「タグ付け」することができるため、ホストの開発/テストコピーの構築、パッケージのアップグレード、必要に応じた構成変更、テスト、および運用へのマージが非常に簡単です。

pxeルートを下る場合は、必ずご覧ください

http://etherboot.org/wiki/index.php

Gpxeにより、ブートターゲットの柔軟性が向上します。aoeブレードを起動するのは非常に簡単で、リモートのhttpサーバーからカーネルを起動するようなものはありません!!!!!!!!!! :-)。

どのサーバーの稼働時間が必要ですか？

セキュリティパッチとソフトウェアアップグレードを常に適用する必要があるため、完璧なイメージを作成することは不可能です。インターネットに接続している場合、パッチを無視することはできません。

pxe側には、クラスターのファイルI / Oに応じていくつかのオプションがあります。カーネルを起動し、ディスクをリモートでaoeまたはiscsi経由でマウントします。

また、コピーオンライトイメージを使用して、非常に巧妙な操作を行うこともできます。アップグレードおよび問題のある変更のロールバックに最適です。

また、クラスター化されたnfsソリューションを使用して、nfs rootを使用して成功しました。クライアントアドレスに応じて、異なるファイルを提供するように指定できます。

繰り返しますが、アプリケーションがnfsの実行を好むかどうかを確認する必要があります。すべてのワークロードに適しているわけではありません。

クラスタ化されたnfsサーバーには、192.168.0.1：/ etc / hostname 192.168.0.2:/etc/hostnameを含めることができます

したがって、すべてのクライアントは同じファイルを参照しますが、クライアントに関連するファイルが提供されます。それはかなり印象的なものですが、簡単ではありません！

ネットワークストレージにファイルシステムを集中化すると、これらすべてにより、ロールアウト時間が短縮されます。ネットワーク経由でリモートディスクにオペレーティングシステムをイメージングするには時間がかかります!!!!

これらのソリューションのいずれかを使用する場合は、適切に設計されたフォールトトレラントネットワークレイヤーがあり、nfs / SANサーバーが適切に設計され、安全であることを確認してください。

NFS / SANの接続が失われると、サーバーの状態が悪化します。:-(

ブートプロセスを制御するためのtftp / pxe用のスクリプトを作成するのは非常に簡単です。

あなたが実際にクラスター化しようとしていることをもっと知っていれば、おそらくあなたにより適したソリューションを考えることができます。