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

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

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

CentOS 5.8 および BFC 3.7 のアップグレード

BFC 3.7 の新規インストールを実行する場合、CentOS 5.8 がシステムにインストールされていることを確認する必要があります。 （注： BFC ベア メタルのインストール機能を使用する場合、CentOS 5.8 のインストールはベア メタルのインストール プロセスの一部として自動的に実行されます）。

BFC を 3.5.0 （またはそれ以前）から 3.7 にアップグレードする場合、CentOS 5.8 にアップグレードする必要があります。 CentOS 5.5 から CentOS 5.8 にアップグレードするには、以下のプロセスを使用します。

ローカルに設定された yum リポジトリで CentOS をアップグレードするには、以下の手順に従います。

1. CentOS 5.8 イメージを www.centos.org からダウンロードします。 ダウンロードには 2 つの DVD の iso ファイル（DVD1 および DVD2）が含まている必要があります。 BFC マシンにダウンロードしたファイルをコピーします。
2. BFC サービスのシャットダウン（service bfc stop）
3. CentOS を 5.5 から 5.8 にアップグレードする BFC マシンで、以下のコマンドを実行して CentOS 5.5 がインストールされていて、アップグレードの準備ができているかを確認します。

   rpm -import /mnt/CentOS/5.5/RPM-GPG-KEY-CentOS-5
   

   注： この手順は、現在の CentOS 5.5 yum 設定が、yum リポジトリとして /mnt/CentOS/5.5 を指していることを前提としています。

4. BFC マシンで、2 つの DVD の iso ファイルを以下の 2 つのディレクトリに別々にマウントします。

   # mount –r –o loop CentOS5.8-DVD1.iso <dir1>
   

   # mount –r –o loop CentOS5.8-DVD2.iso <dir2>
   

5. ディレクトリ /mnt/centos58/ を作成し、2 つのディレクトリ（dir1 および dir2）のコンテンツを /mnt/centos58/にコピーします。
6. /etc/yum.conf の「baseurl=」パラメータを更新します。

   baseurl=file:///mnt/centos58/
   

7. 以下の YUM コマンドを実行します。

   yum update
   

8. 更新されたパッケージ（例： カーネル パッケージ）のために、BFC ノードを再起動して永続的にします。
9. 以下の YUM コマンドを実行し、CentOS 5.8 パッケージのリストを表示します。

   yum list
   

オンラインの yum リポジトリで CentOS をアップグレードするには、以下の手順に従います。

1. /etc/yum.repos.d/ ディレクトリが存在することを確認します。
2. BFC マシンにインターネット アクセスがあるかどうかを確認します（wget コマンドを使用してインターネットからあらゆるファイルを取得します）。
3. yum update を実行して、現在インストールされている CentOS 5.5 パッケージから CentOS 5.8 バージョンに更新します。
4. 更新されたパッケージ（例： カーネル パッケージ）のために、BFC ノードを再起動して永続的にします。
5. yum list を実行して CentOS 5.8 パッケージを一覧します。

   注： 詳細については、yum 設定用に CentOS マニュアルを参照してください。

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

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

注： SAN を使用するように設定されている CA AppLogic® 3.5 ESX ベースのグリッドをアップグレードするには、3.7 へのアップグレードを実行する前に、hf8315 を 3.5 グリッドに適用する必要があります（そうでない場合、アップグレードは失敗します）。 これは、SAN を使用するように設定されている ESX ベースの 3.5 グリッドにのみ適用されます。

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

Solaris ベースのアプライアンスが CA AppLogic® 3.7 でサポートされなくなったことに留意してください。

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

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

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

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

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

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

以下の手順に従います。

1. 3.x グリッドにアプライアンスをインポートするには、class import コマンドを使用します（または、必要に応じてカスタム カタログまたはアプリケーションをインポートします）。 新しい 3.x の ADL 記述子フォーマットを使用するために更新するアプライアンスを含むものをすべてインポートします。
2. アプライアンスがシングルトンでない場合は、新しいアプリケーションを作成し、アプリケーションにアプライアンスのインスタンスをドラッグして、アプライアンスをブランチ化します。 アプライアンスがシングルトンである場合は、インフラストラクチャ エディタでアプリケーションを編集します。
3. アプライアンス クラスを変更し、［一般］タブの［詳細］セクションで、アプライアンスと互換性があるハイパーバイザをベースとして、適切な仮想化モードを選択します（アプライアンスが選択されたすべてのモードをサポートする限り、複数のモードを選択できます）。
4. 仮想化モードの隣の［オプション］ボタンを選択して、以下の手順を実行します。
   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
      • Microsoft Windows 7 （32 ビット/64 ビット）： windows7
      • Microsoft Windows 7 （64 ビット）： windows7-64
      • Linux （32 ビット）の場合： rhel6
      • Linux （64 ビット）の場合： rhel6-64
      • その他（32 ビット）： other
      • その他（64 ビット）： other-64

      たとえば、アプライアンスが Microsoft Windows Server 2008 （32 ビット）をベースとしている場合は、［オプション］フィールドを esx_os_name=longhorn という設定で更新します。

5. アプリケーションを保存します。
6. アプライアンスを開始し、操作可能であることを確認します。
7. カタログからのアプライアンスである場合は、アプライアンスをカタログに戻します。

   これで、新しい 3.ｘ の ADL 記述子フォーマットを使用できるようにアプライアンスが更新されます。

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

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

1. 前述のセクションで指定したように、更新された 3.x の ADL 記述子フォーマットがアプライアンスで使用されていることを確認します。
2. 変換されるアプライアンスに関して、以下の条件が当てはまることを確認します。
   • アプライアンスには grub がインストールされています。
   • grub の環境設定に /boot/grub/menu.lst を使用している場合（Ubuntu および Debian の場合）、この手順を実行した後に grub を更新しないでください。更新すると、grub の環境設定がデフォルトに戻り、アプライアンスがブートできなくなります。 CentOS ベースのアプライアンスには影響しません。
3. 3.x グリッドにアプライアンスをインポートするには、class import コマンドを使用します（または、必要に応じてカスタム カタログまたはアプリケーションをインポートします）。 更新するアプライアンスを含むものをすべてインポートします。
4. アプライアンスがシングルトンでない場合は、新しいアプリケーションを作成し、アプリケーションにアプライアンスのインスタンスをドラッグし、アプライアンスを分岐させます。 アプライアンスがシングルトンである場合は、インフラストラクチャ エディタでアプリケーションを編集します。
5. パーティション化された空のブート ボリュームを作成します。 サイズは、既存のブート ボリューム（異なるサイズが必要な場合を除く） + 新しいカーネルに必要なサイズ（通常は約 50 MB）になるように、概算で設定する必要があります。
   • vol create my-app:boot_vol par1.size=150M
6. 前の手順で作成したパーティション化済みのボリュームに、古いブート ボリュームのデータをコピーします。
   • vol copy my-app:LUX5.boot my-app:boot_vol%par1 --fscpy
7. 古いブート ボリュームを新しいパーティション化済みボリュームに置換します。
   • vol copy my-app:boot_vol my-app:LUX5.boot --overwrite --force
   • vol destroy my-app:boot_vol -f
8. ブート ボリュームを管理します。
   • vol manage _GLOBAL_RO:apk_linux my-app:LUX5.boot -rw
9. ファイラの 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. ファイラ コンソールを終了します
2. インフラストラクチャ エディタで、以下のようにクラスを編集して変更します。
   1. /dev/hdX を使用するように、アプライアンスのデバイス スキーマを変更します
   2. ボリュームのデバイス名を以下のように更新します。
      • /dev/hda1 -> /dev/hda
      • /dev/hda2 -> /dev/hdb
      • /dev/hda3 -> /dev/hdc
      • /dev/hda4 -> /dev/hdd
3. アプリケーションを保存します。
4. アプライアンスを開始し、操作可能であることを確認します。
5. カタログからのアプライアンスである場合は、アプライアンスをカタログに戻します。

   これで、アプライアンスが CA AppLogic® グリッドの Xen および ESX Server の両方でブートできるように更新されます。

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