Windows アプライアンスは、Windows APK msi を組み込むことによって完全に管理できます。Windows APK msi は、CA AppLogic® に含まれる Windows exe インストーラによってインストールされます。
windows_apk-ver.msi バージョンはサポートされているすべての Windows バージョンと互換性があります。
APK をインストールするには、以下が必要です。
注： Windows をインストールするには、OS インストール用の ISO イメージを確認してください。
このセクションには、以下のトピックが含まれています。
動作特性
Windows APK を使用する Windows アプライアンスの動作特性は次のとおりです。
ページ ファイルは Windows アプライアンスでサポートされています。 デフォルトではそれらを有効にしないでください。 すべての Windows アプライアンス ビルドの手順では、ページ ファイルを無効にするよう指示されています。これは、RAM を使用した場合と比較して、スワップ ファイルを使用するとパフォーマンスが低下するためです。 特に、パフォーマンス クリティカルなアプリケーションの場合は、アプライアンスにスワップ ファイルを与えるより、メモリを多くする方がよいことです。
たとえば、データベースを実行する場合、ディスクにスワップ アウトすると処理が遅くなります。 十分な実 RAM を提供できない場合、スワップ ファイルを使用することで RAM を使用するディスクをエミュレートします。 スワップ ファイルが無効になっている場合でも、Windows では、未使用のプログラム コードが含まれるメモリ ページを解放するためにページングを使用することに注意してください。これは、負荷分散システム上で通常発生する一般的なスワッピングです。 常時稼働のサーバ タイプ アプライアンスを実行している場合、メモリ内にあるすべてが使用中になり、ディスクへのスワップによってパフォーマンスの低下が発生します（これは CA AppLogic® に限ったことではありません）。
重要： Windows アプライアンス内で端子を追加/削除するには、アプライアンスのグラフィック コンソールにログインするための管理者のパスワードを知っている必要があります。 これは、ユーザによる手動操作の際に必要になります。
新しい端子またはディスクが Windows アプライアンスに追加された場合、アプライアンスの次の起動時にユーザによる操作が必要となる場合があります。 端子またはディスクが変更されると、Windows PV ドライバが使用されている場合（Halsign など）、Windows ハードウェア セットアップ ウィザードが起動されることがあります。
この場合、ユーザはアプライアンスのグラフィカル コンソールにログインし、ハードウェア セットアップ ウィザードで順にクリックして、端子またはディスクがアプライアンス内で正しく機能するようにする必要があります。 これには、変更に応じてアプライアンスの再起動や Windows の再アクティベーションが必要になる場合もあります。 これは、アプライアンスの端子またはディスクの変更後に初めて起動する場合のみ必要になります。 その後のアプライアンスの起動ではハードウェア ウィザードが表示されることはありません。
この問題は新しい端子/ディスクがアプライアンスに追加された場合のみ発生します。 アプライアンスの端子またはディスク以外の変更でハードウェア ウィザードが表示される場合は、テクニカル サポートまでお問い合わせください。
注： この問題は、「アプライアンス開発者ガイド」に記載されている手順に従うことによって回避可能です。
CA AppLogic® アプライアンス キット（APK）は、すべてのオペレーティング システムについてボリュームの自動マウントをサポートします。 これにより、アプライアンスの起動後に特定のボリュームが表示されるパスを指定することができます。 たとえば、ボリューム myvol は ¥data の下にマウントします。
Windows アプライアンスのインスタンスがカタログ クラスから作成された場合、または Windows ブート ボリュームのコピーによって作成された場合、結果の OS には元のものと同じコンピュータ セキュリティ識別子（SID）が付けられます。 通常、これは問題にはなりません。
ただし、個別のローカル アカウントに割り当てられる SID は、コンピュータ SID と追加された相対識別子で構成されることに注意してください。 コンピュータ SID が同一の場合、2 つの異なるアプライアンス上でユーザ アカウントが同じ SID で作成される可能性があります。 これは、ドメイン アカウントがドメイン SID に基づいているドメインベースの環境では問題になりませんが、セキュリティがローカル アカウント SID に基づくワークグループ環境では問題になる場合があります。
アプライアンス上のコンピュータ SID を変更するには、CA AppLogic® で提供される wincfg ユーティリティを使用してください。 このユーティリティを使用すると、SID、コンピュータ名および管理者パスワードなど、Windows アプライアンスのさまざまな設定を変更できます。 このユーティリティはまた、コンピュータ SID の変更を反映するために Cygwin 環境を更新します。
注： wincfg ユーティリティを使用して、Windows Server 2008 ベースのアプライアンスでコンピュータ SID を変更することはできません。
アプライアンス インスタンス名が変更された場合は常に、Windows アプライアンスのコンピュータ名が CA AppLogic® によって自動的に変更されます。 インスタンス名は、GUI を使用して変更できます。または新しいアプライアンス インスタンスがカタログからアプリケーションに追加される場合も変更できます。 すべての Windows アプライアンスで実行される Windows APK はコンピュータ名変更を処理します。
アプライアンスの起動時に、Windows APK はコンピュータ名をアプライアンス名と比較します。 2 つの名前が異なる場合、APK により次の動作が行われます。
コンピュータ名が更新されている Windows アプライアンスを開始する場合、アプライアンス開始プロセスに通常より数分多く時間がかかります。 これは、コンピュータ名の変更に必要とされるアプライアンス再起動が余分に発生しているためです。
アプライアンスが再起動している間、次のメッセージがコンソールに表示されます： <compname> がメンテナンス状態に入りました（<compname> は Windows コンポーネントの名前です）。
APK がアプライアンスの名前を変更するのを防ぐには、次のように操作します。
Windows VDS exe および Windows Filer exe の両方でこのファイルが作成されます。 VDS コンピュータ名はプロパティによって指定されます。 これはコンピュータ名のファイラにとって関連しません。 Windows Server ベース クラス キット exe MSI はこのファイルを作成しません。
アプライアンスのコンピュータ名を変更するには、Windows GUI を使用するか、またはアプライアンスにログインし、ログイン シェルからの以下のコマンドを実行できます。 これは、前述のように APK コンピュータ名変更が無効化されていることを前提にしています。
以下のコマンドを実行します。
wmic computersystem
where name="%COMPUTERNAME%" rename name="newname"
newname をコンピュータ名で置き換えます。
注： CA AppLogic® に含まれている wincfg ユーティリティを使用すると、Windows アプライアンスのさまざまな設定をユーザが変更できます（コンピュータ名、管理者パスワードなど）。
グラフィカル コンソールにアクセスする必要があるときに Administrator パスワードを知らない場合、ログイン シェルによってパスワードを変更することができます。
以下のコマンドを使用します。
net user Administrator admin-new-password
admin-new-password が Administrator の新しいパスワードです
注：
これが適切でない場合は、上記の手順によってパスワードを変更してください。
この動作を無効にする場合は、実行されているアプライアンス上で Cygwin bash シェルを開いて、スクリプト /appliance/appliance.sh を編集し、最初のコメント ブロックの後に行 exit 0 を挿入します。
Windows MSI インストーラには Cygwin （Windows で実行される簡易的な Linux 類似環境）が含まれています。 Cygwin ssh サーバは、Windows アプライアンスへの ssh アクセスを提供します。 ログイン シェルは bash です。 Cygwin bash シェルは、通常の bash コマンドに加えて、Windows コマンド シェルで使用可能な大部分のコマンドをサポートします。
cygwin シェルでは、ディレクトリ区切り文字として ¥ ではなく / を使用します。
ドライブのルートにアクセスするには、たとえば cd c: または cd c:/ を使用します。cygpath ユーティリティを使用して Cygwin POSIX 形式のパス名と Windows ネイティブ形式のファイル名を切り替えることもできます。詳細については、man cygpath を確認してください。
公開キー認証での ssh ログインのセキュリティ コンテキストは、管理者ログインとほぼ同じですが、厳密に同一ではありません。 現在のユーザの SID は、管理者の SID になりますが、SID の名前のルックアップでは、Administrator の代わりに sshd_service が返されます。
diskpart など一部のコマンドは、ログイン シェルからは機能しません。
Windows MSI インストーラは Windows 自動更新サービスおよび Windows ファイアウォール サービスの両方を無効にします。 これらのサービスは、インストールの後に必要に応じて手動で有効にできます。 詳細については、「APK 準備スクリプトの手動実行」を参照してください。
Windows MSI インストーラは Microsoft Windows ボリュームの自動マウント機能を無効にします。 APK の自動マウント機能はこの機能に優先します。
NTFS ボリューム上で動作する Windows ファイラを使用する前に、ファイラ データ シートで NTFS 実装の詳細を確認してください。
管理対象 Windows アプライアンスは、APK によって生成されるシャットダウン イベントを使用してシャットダウンされます。 場合によっては、たとえば GUI でユーザによる操作を待っている場合でも、Windows がこのイベントをブロックすることができます。 この場合、app stop または comp stop を実行すると、アプライアンスの停止が 15 分でタイムアウトし、アプライアンスは突然停止されて正常にシャットダウンされません。
そのような場合に正常なシャットダウンを実行するには、アプライアンスのグラフィック コンソールにログインし、app stop または comp stop を実行した後に GUI を通じてシャットダウンします。
Windows 固有情報
ファイル名
明記されていない限り、このドキュメント内の名前は、Posix システムをエミュレートする CygWin ファイル ネームスペース内にあります。
注： これらの名前は、Cygwin 以外のユーティリティでは使用できません。 これには、APK バイナリ自体（vme や udlparse など）、およびすべてのネイティブ Windows コマンド ライン ツールが含まれます。 ほとんどの Cygwin ユーティリティは CygWin 名（posix スタイル）または Windows 名（C:¥path¥ など）を受け入れますが、例外的に「:」を含む文字列が computername:filename を意味すると見なすものがあります（たとえば scp、rsync、および特に tar）。 後者の場合、--force-local オプションを使用して強制的に Windows 名を受け入れることができます。
Windows と Cygwin のネームスペース間でファイル名を変換するには、cygpath を使用します。
windowspath=`cygpath -w /var/applogic/appliance.desc`
ディスクのマウント
ディスクのマウント ポイントを指定するときは、必要に応じて以下の名前を使用します。
X - 単一の文字（A、B、D ～ Z）はディスクを X:¥ としてアクセス可能にします。
X:¥ - X と同じ
C:¥dir1¥[dir2¥...] - ディスクをブート ファイル システムの指定されたサブディレクトリ内でアクセス可能にします。 ディレクトリが存在しない場合は作成されます。
注： APK にディレクトリの作成を許可するべきではありません。 デフォルト ディレクトリ許可はユーザのニーズと異なる可能性があります。
ディスクをクラス記述子で指定されたマウント ポイントのない状態にしておくと、APK はディスクを無視し、Windows でのマウント割り当てがそのまま残ります。 この場合、Windows 自体からそのディスクに対して手動で実行されたマウント ポイント割り当ては永続的で、クラス記述子により別のディスクに行われた同じマウント ポイントの割り当てよりも優先されます。 後の割り当てには効果がなく、ディスクはマウントされていない状態になります。 たとえば、クラス エディタ/変更ダイアログ ボックスで以下のように指定したとします。
disk 0 -> （ブート）
disk 1 -> （マウント割り当てなし）
disk 2 -> Z:¥
アプライアンスにログインし、disk2 から Z を削除し、disk1 にそれを割り当てます。 Z は再起動後も disk1 に割り当てられたままです。 クラス記述子の disk2 -> Z 割り当てには効果はありません。 Z が disk1 から削除されるか、disk2 に Z 以外の割り当てが設定されるまで、disk2 はどこにもマウントされません。
C:¥ は予約済みで、どのディスクのマウント ポイントとしても割り当てることができません。 ブート ディスクの割り当てはすべて無視され、アプライアンス インスタンス記述子内の C:¥ にマウントされたものとしてレポートされます。
C: 以外のどのドライブ上でもサブディレクトリのあるマウント パスは使用しないでください。 サブディレクトリのあるマウント パスを使用すると、ディスクのマウント順序に依存するため、マウントを使用できなくなることがあります。
フォーマットされていないディスク、または Windows によって認識されないファイル システムでフォーマットされたディスクのマウントを Windows は拒否しません。 APK がマウントを割り当てるとき、エラーも警告もありません。 ただし、マウント ポイントおよびあらゆるサブパスへのアクセス試行は失敗します。
ユーザ名
APK インストール スクリプトは Administrator 用の CygWin エイリアスを root にします。 そのため、root は任意の CygWin バイナリによって参照されるユーザ名になり、CygWin シェル、およびディレクトリ リストに現在のユーザ名として表示されます。 この設定により、リモート シェル コマンド（3t ssh component-name）を使用してアプライアンスにアクセスできます。
CygWin ユーザ名と Windows ユーザ名の間のマッピングは自動的ではありません。 それは /etc/passwd および /etc/group ファイルに記述されています。これらのファイルは Windows ユーザを追加する/削除するときに自動的に更新されません。 CygWin には、/etc/passwd ファイルと /etc/group ファイルをメンテナンスするためのユーティリティが含まれます。 これらのユーティリティを使用するとき、APK によって作成されたルートに対して特別なマッピングを保存します。 保存しない場合、グリッドからの ssh ログインは動作を停止します。
APK の単独インストール
APK は、Windows Base Class のインストール中に自動的にインストールされます。 必要に応じて、APK を別々にインストールするか、既存のアプライアンス上の APK をアップグレードできます。
APK をライブ システムにインストールする必要があります。 Windows 用の APK は、実際に実行されていないマウントされた OS ディスク イメージにはインストールできません。 最適な結果を得るために、外部ネットワーク アクセスが設定された OS イメージを使用し、任意の OS（rdesktop など）からリモート デスクトップ クライアントを使用してログインします。 外部ネットワーク アクセスが設定されている OS イメージを使用すると、VNC を使用して HVM のエミュレートされたビデオ画面を見るより、操作がよりインタラクティブになります。
以下のいずれかのインストール オプションを実行します。
APK 自動準備スクリプトを含む、Windows APK をインストールするインストール ウィザードを提供します。
ユーザが APK 準備スクリプトを実行するかどうか決定できるインストール ウィザードを提供します。 このスクリプトを実行した場合、必要なシステム設定を有効にするために手動でオペレーティング システムを再起動する必要があります。
ユーザ プロンプトがなく、APK 準備スクリプトを実行するインストールを実行できます。 以下のコマンドを使用します。
msiexec /q /i Windows_APK*.msi
ユーザ プロンプトがなく、APK 準備スクリプトを実行しないインストールを実行できます。
以下のコマンドを使用します。
msiexec /q /i Windows_APK*.msi ADDLOCAL=APK
注： APK 準備スクリプトを無効にする場合は、自動手順を手動で実行します。
|
Copyright © 2013 CA.
All rights reserved.
|
|