インストール、アップグレード、マイグレーション

準備 › リリースノート › インストール時の考慮事項 › インストール、アップグレード、マイグレーション

インストール、アップグレード、マイグレーション

このセクションでは、CA AppLogic 3.5 をインストール、アップグレード、およびマイグレートする方法について説明します。

BFC による ALD の置き換え

ALD は、グリッドのインストールおよびアップグレードには使用されなくなりました。 ALD に代わる機能は、Backbone Fabric Controller （BFC）です。 BFC には、1 つのバックボーン内のすべての CA AppLogic グリッドを作成および管理するために使用する、使いやすい Web ベースの GUI アプリケーションが含まれています。 BFC は、最新の CA AppLogic リリースおよびホットフィックスを自動的にダウンロードします。

BFC のドキュメントには、BFC をダウンロード/インストールする方法、および BFC を使用して CA AppLogic グリッドを管理する方法に関する情報が含まれています。

既存のグリッドからのアップグレード

Xen ベースのグリッドの場合は、既存の CA AppLogic バージョン 3.0 およびリリース 3.1 グリッドから最新のリリース（3.5）へのアップグレードが完全にサポートされています。 ESX ベースのグリッドの場合は、CA AppLogic 3.1 から最新のリリース（3.5）へのアップグレードが完全にサポートされています。 3.0 より前（2.9 や 2.8 など）の CA AppLogic リリースからのアップグレードはサポートされていません。以前の CA AppLogic グリッドを最新のリリースにマイグレートするには、CA AppLogic 3.5 をインストールし、カスタムアプリケーションおよびカタログを古いグリッドから新しい 3.5 グリッドにマイグレートする必要があります。このセクションの残りのトピックでは、アプリケーションおよびカタログを新しいグリッドにマイグレートする方法について説明します。

注： Xen ベースの 3.0.x グリッドをアップグレードするには、BFC のドキュメントを参照してください。

CA AppLogic 3.5 は、以前の CA AppLogic リリースで作成されたアプライアンスおよびアプリケーションをサポートしています。アプライアンスのタイプ、および必要なハイパーバイザのタイプによっては、3.5 のグリッド上で使用する前にアプライアンスを更新する必要がある場合があります。

アプリケーションに対する変更の決定

アプリケーションを 3.5 グリッドで実行するために必要な変更の種類を判断するには（必要な場合）、以下のガイドラインに従います。

3.0 または 3.1 グリッドから 3.5 グリッド（Xen または ESX ベース）にアプライアンスを移動する場合、何も変更を加えなくてもすべてこれまでどおりに機能します。
2.9 グリッド（またはそれ以前のバージョン）から 3.5 の Xen ベースのグリッドにアプライアンスを移動する場合、何も変更を加えなくてもすべてがこれまでどおりに機能します。
2.9 グリッド（またはそれ以前）から 3.5 の ESX ベースのグリッドに Windows ベースのアプライアンスを移動する場合、記述子を新しい 3.x のフォーマット（以下を参照）に更新する必要があります。また、最新の APK （アプライアンスキット）をアプライアンスに再インストールし、vmware ツールもアプライアンスにインストールする必要があります（vmware ツールは VMware の Web サイトからダウンロードできます）。
2.9 グリッド（またはそれ以前）から 3.5 の ESX ベースのグリッドに Linux ベースのアプライアンスを移動する場合、記述子を新しい 3.ｘのフォーマット（以下を参照）に更新する必要があります。また、ESX をサポートするためにブートディスクを更新する必要があります（以下を参照）。
アプライアンスが 10 個より多くの端子を持っており、ESX ベースのグリッドでアプライアンスを実行する予定である場合、新しい 3.x のフォーマット（以下を参照）を使用するように記述子を更新する必要があります。また、アプライアンスに最新の APK （アプライアンスキット）を再インストールする必要があります。

アプライアンス記述子の更新

新しい 3.x のフォーマットを使用するようにアプライアンス記述子を更新するには、以下の手順に従ってください。

注：この手順は、ESX ハイパーバイザ上で実行する、以前の CA AppLogic リリースのアプライアンスがある場合に実行します。

Follow these steps:

3.x グリッドにアプライアンスをインポートするには、class import コマンドを使用します（または、必要に応じてカスタムカタログまたはアプリケーションをインポートします）。新しい 3.x の ADL 記述子フォーマットを使用するために更新するアプライアンスを含むものをすべてインポートします。
アプライアンスがシングルトンでない場合は、新しいアプリケーションを作成し、アプリケーションにアプライアンスのインスタンスをドラッグし、アプライアンスを分岐させます。アプライアンスがシングルトンである場合は、インフラストラクチャエディタでアプリケーションを編集します。
アプライアンスクラスを変更し、［一般］タブの［詳細］セクションで、アプライアンスと互換性があるハイパーバイザをベースとして、適切な仮想化モードを選択します（アプライアンスが選択されたすべてのモードをサポートする限り、複数のモードを選択できます）。
仮想化モードの隣の［オプション］ボタンを選択して、以下の手順を実行します。
1. VMWare 仮想化モードを選択します。
2. ［オプション］フィールドで、esx_os_name という名前の新しい設定を追加します。その値は以下のいずれかになります。
  - Microsoft Windows Server 2003, Datacenter Edition （64 ビット）の場合： winNetDatacenter-64
  - Microsoft Windows Server 2003, Enterprise Edition （64 ビット）の場合： winNetEnterprise-64
  - Microsoft Windows Server 2003, Standard Edition （64 ビット）の場合： winNetStandard-64
  - Microsoft Windows Server 2003, Datacenter Edition （32 ビット）の場合： winNetDatacenter
  - Microsoft Windows Server 2003, Enterprise Edition （32 ビット）の場合： winNetEnterprise
  - Microsoft Windows Server 2003, Standard Edition （32 ビット）の場合： winNetStandard
  - Microsoft Windows Server 2003, Web Edition の場合： winNetWeb
  - Microsoft Windows Server 2008 R2 （64 ビット）の場合： windows7srv-64
  - Microsoft Windows Server 2008 （32 ビット）の場合： longhorn
  - Linux （32 ビット）の場合： rhel6
  - Linux （64 ビット）の場合： rhel6-64
  - Sun Solaris 10 （32 ビット）の場合： solaris10
  - Sun Solaris 10 （64 ビット）の場合： solaris10-64
  - その他（32 ビット）： other
  - その他（64 ビット）： other-64
  たとえば、アプライアンスが Microsoft Windows Server 2008 （32 ビット）をベースとしている場合は、［オプション］フィールドを esx_os_name=longhorn という設定で更新します。
アプリケーションを保存します。
アプライアンスを開始し、操作可能であることを確認します。
カタログからのアプライアンスである場合は、アプライアンスをカタログに戻します。
これで、新しい 3.ｘの ADL 記述子フォーマットを使用できるようにアプライアンスが更新されます。

アプライアンスブートボリュームの更新

3.x グリッドの Xen および ESX ベースの両方のサーバで動作するようにアプライアンスのブートボリューム（Linux ベース）を更新する方法については、以下の手順に従います。

前述のセクションで指定したように、更新された 3.x の ADL 記述子フォーマットがアプライアンスで使用されていることを確認します。
変換されるアプライアンスに関して、以下の条件が当てはまることを確認します。
- アプライアンスには grub がインストールされています。
- grub の環境設定に /boot/grub/menu.lst を使用している場合（Ubuntu および Debian の場合）、この手順を実行した後に grub を更新しないでください。更新すると、grub の環境設定がデフォルトに戻り、アプライアンスがブートできなくなります。 CentOS ベースのアプライアンスには影響しません。
3.x グリッドにアプライアンスをインポートするには、class import コマンドを使用します（または、必要に応じてカスタムカタログまたはアプリケーションをインポートします）。更新するアプライアンスを含むものをすべてインポートします。
アプライアンスがシングルトンでない場合は、新しいアプリケーションを作成し、アプリケーションにアプライアンスのインスタンスをドラッグし、アプライアンスを分岐させます。アプライアンスがシングルトンである場合は、インフラストラクチャエディタでアプリケーションを編集します。
パーティション化された空のブートボリュームを作成します。サイズは、既存のブートボリューム（異なるサイズが必要な場合を除く） + 新しいカーネルに必要なサイズ（通常は約 50 MB）になるように、概算で設定する必要があります。
- vol create my-app:boot_vol par1.size=150M
前の手順で作成したパーティション化済みのボリュームに、古いブートボリュームのデータをコピーします。
- vol copy my-app:LUX5.boot my-app:boot_vol%par1 --fscpy
古いブートボリュームを新しいパーティション化済みボリュームに置換します。
- vol copy my-app:boot_vol my-app:LUX5.boot --overwrite --force
- vol destroy my-app:boot_vol -f
ブートボリュームを管理します。
- vol manage _GLOBAL_RO:apk_linux my-app:LUX5.boot -rw
ファイラの vol manage コンソールで以下のコマンドを実行して、CentOS5 32 ビットカーネル（Linux ファイラが使用しているのと同じカーネル）をインストールします。別のカーネルが必要な場合は、代わりにそのカーネルをコピーし、適切な名前を使用して grub の環境設定を更新します。ブートボリュームは /mnt/vol2/par1 にマウントされます。
- cp -a /boot/{initrd-2.6.18-238.9.1.el5PAE.img,vmlinuz-2.6.18-238.9.1.el5PAE} /mnt/vol2/par1/boot/
- cp -a /lib/modules/2.6.18-238.9.1.el5PAE /mnt/vol2/par1/lib/modules/
- sed -i -e 's#/dev/hda2#/dev/hdb#' -e 's#/dev/hda3#/dev/hdc#' -e 's#/dev/hda4#/dev/hdd#' /mnt/vol2/par1/etc/fstab
- tar -xvf /mnt/vol/apk-2.0.36-linux-rh.tar.gz -C /mnt/vol2/par1 （ご使用のディストリビューション用 APK に置換します。CA AppLogic 3.ｘリリースの最新の APK を使用していることを確認します）
- cd /mnt/vol2/par1
- tmp/apk-install
- sed -i -e 's/tty1/console/' /mnt/vol2/par1/etc/inittab
```
cat << EOF > /mnt/vol2/par1/boot/grub/grub.conf
default 0
timeout 1

title CA AppLogic Appliance
        root    (hd0,0)
        kernel  /boot/vmlinuz-2.6.18-238.9.1.el5PAE root=/dev/hda1 ro console=tty0 console=ttyS0,38400n8
        initrd  /boot/initrd-2.6.18-238.9.1.el5PAE.img
EOF

fs=$(grep "^/dev/sdc1" /proc/mounts 2>/dev/null|awk '{print $3}')
[ "$fs" == "ext3" -o "$fs" == "ext2" ] && fs=e2fs

out=$(grub --batch --no-floppy 2>&1 <<EOF   
device (hd0) /dev/sdc
root (hd0,0)
embed /boot/grub/${fs}_stage1_5 (hd0)
EOF
）

sectors=$(grep 'sectors are embedded' <<< "$out" |grep -Eo '[[:digit:]]+')

grub --batch --no-floppy <<EOF   
device (hd0) /dev/sdc
root (hd0,0)
install --stage2=/mnt/vol2/par1/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+${sectors} p (hd0,0)/boot/grub/stage2 (hd0,0)/boot/grub/grub.conf
quit
EOF
```

重要： ブートボリュームのボリュームを管理する場合、すべての読み取り専用ボリュームを読み取り専用としてマークするために fstab （/mnt/vol2/par1/etc/fstab）を更新します。この作業を行わないと、アプライアンスがブートしません。

ファイラコンソールを終了します
インフラストラクチャエディタで、以下のようにクラスを編集して変更します。
1. /dev/hdX を使用するように、アプライアンスのデバイススキーマを変更します
2. ボリュームのデバイス名を以下のように更新します。
  - /dev/hda1 -> /dev/hda
  - /dev/hda2 -> /dev/hdb
  - /dev/hda3 -> /dev/hdc
  - /dev/hda4 -> /dev/hdd
アプリケーションを保存します。
アプライアンスを開始し、操作可能であることを確認します。
カタログからのアプライアンスである場合は、アプライアンスをカタログに戻します。
これで、アプライアンスが CA AppLogic グリッドの Xen および ESX Server の両方でブートできるように更新されます。

注： CA AppLogic 3.x に含まれているすべてのカタログとアプリケーションは、Xen または ESX のいずれかで動作できるように更新されています。 Xen または ESX のいずれかで実行できるように、CA AppLogic 3.x アプライアンスでカスタムアプライアンスのベースを変更するように選択できます。この場合は、前述の手順に従う必要はありません。

新しい Windows APK へのアップグレード

ベータから参加した場合、ベータに含まれているバージョン（APK バージョン 3.5.4）から GA に含まれている新しい Windows APK バージョン（APK バージョン 3.5.14）にアップグレードできます。

Windows_APK.*.msi をアップグレードする場合、GA バージョンをインストールする前に以下のディレクトリリンクを削除します。

/lib/applogic
/etc/sysconfig
/var/run/applogic

インストール、アップグレード、マイグレーション

BFC による ALD の置き換え

既存のグリッドからのアップグレード

アプリケーションに対する変更の決定

アプライアンス記述子の更新

アプライアンス ブート ボリュームの更新

新しい Windows APK へのアップグレード

アプライアンスブートボリュームの更新