自動インストールとドライブイメージング


9

自動インストールとドライブイメージングによる展開のメリットとデメリットは何ですか?Windowsの場合、ドライブのクローンを作成するときにSIDの生成に問題があることを知っています。イメージを介してLinuxを展開する場合に同様の問題はありますか?

回答:


3

私はここの答えのいくつかに同意しません。正しく行われると、イメージを取得して、異なるハードウェアを使用して複数のシステムにロードできます。個人的には、最大30の異なるシステムをサポートする画像を見てきました。

あなたの質問に対する私の答えは、あなたがイメージの作成について非常に肛門であるならば、両方の方法を使うことです。自動インストールを作成し、結果をsysprepします。これにより、繰り返し可能な自己文書化された画像が作成されます。

また、保存された状態でディスクイメージに書き込むことができる場合は、sysprep中に実行できるスクリプトを含めることにより、イメージの内容を拡張できます。または、sysprepを実行する前にシステムをバックアップし、それを拡張してからsysprepを実行することもできます。

私は両方の方法を実行して、良い結果を得ました。

SIDの問題については、新しいイメージには常にSysprepを使用する必要があります(NewSIDは機能します)。これにより、SIDの問題が解決されます。ただし、レジストリにGUIDを書き込み、クリーニングする必要のある他のアプリケーションがあります。私の頭の上のAltirisとWSUSはこれを行う2つです。


1
+1-異なるハードウェアに対して適切なイメージングを実行できます。
ロマンダス2009年

3

イメージングは​​命を落とすものです。CentOSキックスタートの完全インストールには10分もかかりません。インストールが大幅に遅い場合は、調査する価値のある問題です。

イメージングの問題は、ビルドに変更を加えるときに「ゴールデン」コピーを保持して更新する必要があることです。これは、無人インストールのメカニズムが依然として必要であることを意味します。変更するたびに、そのようなインストールを実行し、イメージを変更し(環境の自動カスタマイズのメカニズムが必要)、このコピーをゴールデンコピーにする必要があります。ゴールデンコピーに直接変更を加える場合は、何年にもわたるパッチ適用やアップグレードなどを行った後、すぐに混乱を招くでしょう。

システムをイメージ化する必要がある場合は、OSのデフォルトビルドをイメージ化し、ポストインストール作業(ローカルのカスタマイズ)を新しいマシンごとに個別に実行する必要があります。このようにすると、ビルドにささいな変更を加えるだけでゴールデンコピーを再ビルドする必要がなくなります。

ハードウェアがすべて同じではない場合は、インストーラーの自動検出/構成を利用できます。RedHat / CentOS 3、4、5とすべての種類のハードウェア間で実質的に同一のキックスタート構成を使用しました。

私が今まで見た中で最悪の結果は、ゴールデンイメージ(およびマルチパックを使用したdd)を使用してSolarisシステムをインストールするシステムでした。彼らのインストーラーとパッチはとても遅いので、これは理にかなっているように見えました。残念ながら、インストールされたシステムのハードウェアを完全に変更することは簡単ではありません。各ハードウェアタイプには、独自のゴールデンイメージがありました。ささいなビルド変更では、数十のディスクに変更を加える必要があります。2番目に悪いのは、Kickstartを使用したLinuxグループと比較して、Windowsグループのイメージングマシン(インストーラーが壊れているために合理的)でした。Linuxグループは、たとえばDNS構成の変更を数分で展開できます。(ポストインストール、テストビルド、および既存のマシンへの構成の手動プッシュを変更するには1分)。Windowsグループは、各ゴールデンイメージを起動して変更を加える必要がありました。ゴールデンイメージの起動によって生じた問題を元に戻し、テストビルドを実行します。(また、複数のマシンのシステム構成の変更を自動化し、既存のマシンを変更するための特別なツールを購入する必要がありました)。Windowsグループには、ゴールデンイメージを再インストールして変更を加えるオプションもありましたが、OSと数十のアプリケーションを手動でインストールしたため、毎週若干のテストが必要になり、本番システムのリスクが低下するリスクがありました。それ以外の場合と同じです。

どちらの場合も、ゴールデンイメージを使用するWindowsとSolarisのセットアップは可能な限り最善の方法で処理されず、管理者が行った選択の一部は能力の欠如であることに注意してください。しかし、妥当ではない設計から始めても、役に立ちませんでした。

キックスタートは非常にうまく機能しているため、他の方法を検討する理由もありません(私はそれについて多くの小さな不満を持っていますが、それがイメージングマシンによって行われた場合は、1000倍悪くなります)。インストールプログラムがAnaconda以外のものであり、その自動インストールがキックスタートほど有用でない場合は、そのディストリビューションが本当にエンタープライズ向けであるかどうかを検討する必要があります。


2

ドライブのイメージングは​​より高速ですが、ハードウェアが機能するためには非常に類似している必要があります。イメージをカスタマイズするのも困難です。Webサーバー、電子メールサーバーなどの基本イメージが必要です。自動インストールでは、すべてのマシンを同じネットワークの場所からインストールできますが、サーバーの種類に応じて異なるスクリプトを使用します複数の画像を保存して作成する必要があるのではなく、


1

Linuxについてはコメントできませんが、Windowsでは、イメージに対して自動化されたプロセスを使用するための専門家はそれほど多くありません。

Microsoftから入手できる多くのガイダンスがここにあります

証拠はプリンにあります。Microsoftは現在、Vista、Windows 2008、およびWindows 7のイメージベースの展開を使用しています。上記のリンクで説明されている新しいツールとプロセスを使用すると、WindowsをあらゆるHALタイプ(XPを含む)に展開できます。 。


1

イメージを介してWindowsを展開することは、展開する前にSysprepを使用してイメージを "工場出荷時に封印"することでMicrosoftによって完全にサポートされています。SysprepはSIDをリセットし、基本的に新しいマシンのイメージを準備します。

ただし、簡単な理由から、完全にスクリプト化されたインストールを行うことを強くお勧めします(小規模な会社でない限り)。イメージを更新する必要がある場合は常に、2つのオプションがあります。

1)既存のイメージを継続的に変更し、毎回再sysprepします。同じイメージを何度もパッチ、修正、sysprepし続けると、最終的に問題が発生します。

2)イメージを最初から再作成します。これは非常に望ましい方法です。ただし、スクリプトビルドがない場合は、ビルド間で多くの不整合が発生するリスクが高くなります。

つまり、要約すると:

  • スクリプトビルドを使用してイメージを作成する
  • イメージを展開に使用する

さらに、Windows Vista、2008、および7はすべてイメージベースのインストールを使用しているため、イメージベースのインストールとスクリプトによるインストールを使用するメリットがなくなっています。


0

インストールするアプリケーションと、イメージを更新しないでおく期間によって異なります。

毎月かなり多くの更新があるので、画像からボックスを復元した後でも、アップグレードする必要があります。

SIDについて-私が知る限り、一意の秘密鍵(ssh、https、tls、たとえば、smtp / pop3サーバーなど)を生成すれば十分です。また、一意のホスト名の生成も便利です。これはディストリビューションによって異なる場合があります。私は主にdebianを使用しており、そのosで仮想マシンのクローンを作成するのに問題はありませんでした。


1
Active Directoryドメインに参加している場合、SIDが重複すると問題が発生します。SysprepのとNewSID - technet.microsoft.com/en-us/sysinternals/bb897418.aspxは -かかわらず、使いやすい十分です。
Kara Marfia、2009年


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.