複数のサーバーにわたるアプリケーションの管理、またはPXEとcfEngine / Chef / Puppet
いくつかの（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.） パペット 構成管理用。理想的には、cobblerで構築されたホストは、起動時にパペットサーバーに電話をかけるのに十分なjustを知っている非常に重要な構成です。その後、Puppetは構成設定を適用し、環境全体でそれらの設定を永続的に維持します。
3.） Func 複数のマシンへのアドホックコマンドを並列に実行します。たとえば、「コードの新しいsvnチェックアウトをデプロイし、Apacheを再起動する」などです。 funcを使用して、cluster-sshのようにサーバーのグループで同じbashコマンドを呼び出すのは非常に簡単です。あなたが本当にそれに入りたいなら、あなたはいくつかの本当にシンプルなPythonでそれのためにあなた自身のモジュールを書くことができます。
これらの3つのツールにはすべて、freenodeを支援するための優れたwikiとアクティブなircチャネルがあります。
概観
いくつかの点で、ここで2つの質問があります。
- 標準サーバーを構築して維持するにはどうすればよいですか？
- 標準構成を維持し、後で変更するにはどうすればよいですか？
私はこれらの2つのことを別々に扱う以下の私の答えを分けましたが、それらは非常に密接に関連しています。ここではテクノロジーソリューションについて取り上げていますが、変更管理など、関連するベストプラクティスについては取り上げていません。
これが質問の範囲をカバーしていない場合は、明確にしてください。詳しく説明させていただきます。これは必要な基盤であり、適切に実行されているテクノロジインフラストラクチャにとって重要です。
サーバーの構築
UNIXの世界ではイメージは好きではありません。これは、Windowsスタイルのアプローチの詳細です。一部のWindowsの人々でさえ、今では標準ビルドのスクリプトに再び焦点を合わせているようです。
衛星は、RHELの世界でやや人気が高まっているようです。 Spacewalkは、オープンソース版です。これを使用するには、完全にRHELアプローチを使用する必要があります。これは、サーバー構築と構成管理の両方として機能します。
理想的には、必要なすべてのソフトウェアについて、ファイルサーバー上にローカルのミラーとリポジトリを確立する必要があります。
まず、RHEL/CentOSのKickstartなど、ディストリビューションビルドの自動化を利用します。キックスタートは、ニーズに応じて、バリエーションを持つベースラインになります。キックスタートビルドは、PXEサーバーから開始できます。
ビルドのより高度な部分や、キックスタートファイルに適さないものについては、独自のカスタムスクリプトを作成できます。ただし、カスタムスクリプトではなく、puppetまたはcfengineがうまく機能する場合があります。カスタムスクリプトが最も柔軟性があり、単一のアプローチに限定されないことがわかりました。
独自のスクリプトを作成する場合は、ユニバーサル構成のコアスクリプトをお勧めします。これは、セキュリティ構成、強化、およびすべてのビルドに適用されるあらゆるものです。次に、サーバーの役割を確定するための最後のスクリプト。たとえば、Webサーバーやデータベースサーバーなどです。
標準の維持
あなたが説明することも、構成の維持に該当します。ビルド標準、ソフトウェアの更新などはビルドに関連していますが、多くの点で分離しています。
最も重要なサーバーの役割用に独自のソースベースのビルドを作成するのではなく、システムパッケージに依存することを選択した場合、その多くはネイティブシステムユーティリティで維持できます。これは、サーバーリストに対してforループを実行し、yum -y update packageを実行する単純なスクリプトにすることができます。
構成管理の場合、これはパペット、cfengine、およびその他の場所です 構成管理 ユーティリティが登場します。これらは非常に便利なユーティリティであり、独自のスクリプトを最初から作成しなくても必要な基盤を提供します。
サーバーの構成標準を更新するときは、これを標準のサーバービルドに埋め戻すことが重要です。
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のスクリプトを作成するのは非常に簡単です。
あなたが実際にクラスター化しようとしていることをもっと知っていれば、あなたにもっと適した解決策を考えることができるでしょう。
私は最近、一元化されたビルド/プロビジョニングおよび構成管理システムを$ WORKで展開するという大きなプロジェクトを終えました。 CentOSを実行しています。
私が本当に好きな私のデザインは、いくつかのカスタムPHPスクリプトを使用してすべてを単純なものに結び付けるスクリプトを使用して、実質的にワンクリック（まあ、1つのWeb GUIページ）ビルドプロセスを提供します効果的なウェブUI。
一般的な理論は次のとおりです。
- すべてのインストールを単一の統一された最小限のKickStartファイルから実行します（まあ、1つはx86用、もう1つはx86-64用ですが、最小限のパッケージ選択で実質的に同じファイルです）。
- KickStat postinstallスクリプトブートストラップPuppet。
- Puppetはすべてのノード/ホスト固有の構成、パッケージのインストールなどを適用します。
イメージはUnix-yの方法ではないことに同意します。イメージは、スクリプト化/自動化されたインストールおよび構成がそれほど単純ではないWindowsの世界により適しています。
Puppetは、法案に適合する他の構成管理システムに置き換えることができますが、私はたまたまPuppetの宣言的な性質とその収束の概念を気に入っています。
このシステムには多くの利点があります。
- Puppetは一般的な基本インストール以降のすべてを処理するため、必要なすべてのパッケージと構成が1か所にあります。
- Puppetマニフェストは、低レベルのドキュメントの追加ソースとして機能します。
- Puppetを使い続ける限り（つまり、ローカルの構成を変更したり、それらをPuppetにマージしたりしないでください）、マシンの複製を作成するのは簡単です。
- すべてのホストは共通のベースから構築されているため、ベース（KickStart）パッケージセットを使用してハードウェアまたはVMをプレインストールし、必要に応じてクラスを追加するだけでそれらを機能ノードに変えることができます。
- Puppetを使用すると、本番または開発用にホストに「タグを付ける」ことができるため、ホストの開発/テスト用コピーの構築、パッケージのアップグレード、または必要に応じた構成の変更、テスト、そして本番環境へのマージが非常に簡単になります。