Jon Senger、Aik Zu Shyong、Suzanne Zorn 著
たったひとつのサーバーでもオペレーティング・システムの切り替えは、簡単な問題ではありません。 関連する変換や互換性の問題の対応も同様です。 Dell のように、世界中に非常に多く展開しているサーバーの全オペレーティング・システムの切り替えに必要な作業を想像してみてください。
|
Dell は、2010年6月にハードウェアおよびアプリケーション・レイヤーを変更せずに、1,700のシステムを SUSE Linux から Oracle Linux に移行することを決定いたしました。 Linux プラットフォームの持つ標準規格によって、この大規模なコンバージョンが可能になりました。 サイト固有のオペレーティング・システムやアプリケーションの構成の大部分は、単純にバックアップを取って新しいオペレーティング・システムに直接リストアを行う事で元の状態に戻す事が出来ています。 構成変更は最小限で、ほとんどが自動化出来、必要な管理作業も簡単で、信頼性の高い一貫した移行手順が可能でした。
この移行プロセスの当初、Dell には SUSE Linux で動作している物理システムが約1,700ありました。 これらのシステムは世界中に分散しており、第8世代(Dell PowerEdge 2850および2950サーバー)と、より新しい Dell ハードウェアが混在していました。 ファイバ・チャネル SAN ストレージは、EMC Symmetrix デバイスと CLARiiON デバイスで構成されていました。 ソフトウェア環境には、図1のように SUSE Linux 10 Service Pack 1(マルチパスI/O(MPIO)を含む)、 Oracle Database 10g Release 2、Oracle Real Application Clusters(Oracle RAC)、 および Oracle Automatic Storage Management が含まれていました。
図1:Oracle Linux への移行前後の Dell のデプロイメント環境
移行の主要部分は、SUSE Linux 10 から Oracle Linux 5.5 へのオペレーティング・システムの移行でした。 移行中は、同じ物理サーバーとストレージ・ハードウェアが使用されています。 同様に、Oracle ソフトウェアも移行後に変更は行われておりません。 Dell の追加変更は、SUSE Linux の組込みマルチパス I/O サポートから EMC PowerPath に切り替えて、データ・パス管理を自動化することでした。 (注: MPIO から PowerPath への実際の変換はオペレーティング・システム移行の範囲外であるため、このドキュメントでは説明しません。)
また、この移行プロセス中に、SUSE Linux で動作しているサーバー上のアプリケーションを 廃止するか、または既存の MegaGrid 環境にデプロイするかの再評価を行っています。 Dell は、MegaGrid デプロイメントに16ノードのラック(それぞれ300のデータベースをホスト可能)を使用しています。 既存の MegaGrid インフラストラクチャに十分な容量があり、アプリケーションやデータベースをグリッドに移行できたため、 サーバーの電源を落として廃止した場合もありました。 この統合により、電力と冷却が節約され、スペース要件が縮小しました。 統合できなかった場合は、このドキュメントのプロセスを使用して、SUSE Linux システムを Oracle Linux に移行しています。
移行の規模を考えると、プロジェクトの成功には十分な計画と自動化が重要でした。 Dell の Core Engineering である Aik Zu Shyong は、次のように振り返ります。 「簡単で信頼性の高い、繰り返し使用可能な自動プロセスを提供するため、オペレーティング・システム変換の設計に注力しました。 また、時間とコストがかかる変換方式を使用する代わりにインプレースで移行を実行するよう設計したおかげで、ダウンタイムを大幅に減らし、データセンター・スペースを節約できました。」
Dell の移行プロセスには、おもに3つの手順が含まれています。 準備、オペレーティング・システムの再イメージング、およびインストール後の構成です。 まず Dell は、準備手順で既存環境の構成を保存し、アプリケーションとデータベースを安全に停止しました。 次に、オペレーティング・システムを SUSE Linux 10 から Oracle Linux 5.5 に再イメージングしました。 再イメージングの完了後に、インストール後手順を使用して、新しい環境を構成し以前のデータをリストアしました。
Dellは次のインストール前手順を使用して、SUSE Linux から Oracle Linux への移行を準備しました。
ORACLE_HOME
ディレクトリに基づいて)異なっていました。このディレクトリと、バックアップが必要な各種システム構成ファイルの保持に十分な領域を確保しました。init.d
プロセスの無効化。 オラクルが推奨する停止順序に従って、Oracle Database、Oracle Automatic Storage Management、クラスタ・ノード上で実行されているアプリケーション、およびCluster Ready Services(CRS)を停止しました。 実行中のサービスを無効にするには、chkconfig
コマンドを使用しています。 # chkconfig service_name off
lsof
コマンドを使用して開いているファイルをリスト表示し、NFSマウントが使用中でないことを確認しました。 また、ORACLE_HOME
ディレクトリがリソースで使用されていないことを確認しました。# lsof
アーカイブ手順 | コメント |
---|---|
ハードウェア情報 | Dell の OpenManage Server Administrator(OMSA)または Linux のネイティブ・コマンドを使用してハードウェア情報をアーカイブし、ファイル(hardware.txt など)に保存 |
ネットワーク・カード情報 | IP アドレス、サブネットとゲートウェイ情報、MAC アドレス、リンクの速度と二重化情報、およびネットワーク・ボンディングの構成をアーカイブし、ファイル(network.txt など)に保存 |
メモリ情報 | (オプション)メモリ使用量レコードをアーカイブし、必要に応じて1週間の最大使用量のスナップショットを使用して同等またはより優れたパフォーマンスが出ていることを証明し、ファイル(memory.txt など)に保存 |
OS の *-release ファイル | /etc/SuSE-release |
カーネル・モジュール情報 | /lib/modules/* , /etc/{modprobe.conf, modprobe.conf.local, modprobe.d/*} |
認証(PAM)、ユーザーとグループ、および nsswitch.conf | /etc/pam.d/* 、/etc/nsswitch.conf 、/etc/passwd 、/etc/shadow 、/etc/group 、/etc/sudoers 、/etc/security/* |
デバイス・マネージャ(udev )ルール | /etc/udev/udev.conf 、/etc/udev/rules.d/* |
automount ファイル・システム情報 | /etc/auto.* (オプション。automount 使用時のみ必要) |
ブートローダ構成ファイル | /boot/grub/* 、/etc/grub.conf 、/etc/sysconfig/bootloader |
/var/log/messages ファイル | /var/log/{boot.msg, boot.omsg, localmessages, messages} |
runlevel 構成 | /etc/inittab 、/etc/init.d/boot.local |
rclocal スクリプト | /etc/rc.d/rclocal |
cron ジョブ構成 | /etc/cron/{daily, hourly, monthly}/* 、/var/spool/cron/tabs/* |
MPIO 構成 | /etc/multipath.conf |
ネットワーク構成(NIC、ルーティングなど) | /etc/sysconfig/network/ifcfg-* 、/etc/sysconfig/network/* 、/etc/resolv.conf |
NTP 構成 | /etc/ntp.conf |
NFS 構成 | /etc/exports 、/etc/fstab |
ネーム・サービス構成 | /etc/nscd.conf |
ホスト構成 | /etc/{hosts, host.conf, hosts.allow, hosts.deny, HOSTNAME} |
システム構成(sysconfig ) | /etc/sysconfig/* (すべてのサブディレクトリを含む)、/etc/sys/* (すべてのサブディレクトリを含む) |
/proc/info ファイル | /proc/* (すべてのサブディレクトリを含む) |
SSH 構成 | /etc/ssh/* 、/etc/sshd.config 、/etc/pam.d/ssh |
SAR データファイル | /var/log/sa/sa* |
Apache 構成ファイル | オプション(Apache実行時にのみ必要) : /etc/httpd* |
FTP | オプション、FTPサービス実行時にのみ必要 |
CIFS | オプション、CIFSサービス実行時にのみ必要 |
シェル/プロファイル情報 | /etc/{bash.bashrc, csh.cshrc, csh.login, ksh.kshrc} 、/etc/profile 、/etc/profile.d/* |
prelogin メッセージ | /etc/issue |
/etc/default ディレクトリ・ファイル | /etc/default/* |
PowerPath のライセンス供与と構成ファイル | /etc/emcp* |
追加のソフトウェア/アプリケーション | オラクル以外のサード・パーティ製ソフトウェア・アプリケーションをバックアップ |
アーカイブ手順 | コメント |
---|---|
oracle ユーザーと svcgrid ユーザーのプロファイル | oracle ユーザーと svcgrid ユーザーの .profile ファイル(注: Oracle Linux ファイルの名前は .bash_profile です) |
LUN のマッピング情報 | /u02 (このディレクトリには、SUSE Linux 環境での LUN マッピングのシンボリック・リンクが含まれます) |
Oracle インベントリ・ポインタ(oraInst.loc )および oratab ファイル | /etc/oraInst.loc 、/etc/oratab |
Oracle インベントリ・ファイル(oraInventory ) | /etc/oracle/oraInventory |
OCR ファイル | /etc/oracle/ocr.loc |
oracle ユーザーの信頼できる SSH 鍵 | ~oracle/.ssh/* |
データベース固有のカーネル設定 | /etc/sysctl.conf |
oracle ユーザーのホーム・ディレクトリ | サイト固有、Dell構成の/home/oracle |
Oracleソフトウェア(ORACLE_BASE )のホーム・ディレクトリ | サイト固有、Dell構成の/u01/app/oracle |
tar
ユーティリティを使用して、保存した構成ファイルのバックアップ・イメージを作成しました。
構成情報を保存してすべての必須サービスをバックアップ・サーバーに移動したので、システムに新しい Oracle Linux オペレーティング・システムをインストールできる状態になりました。 kickstart インストール方法を使用して、ネットワーク間で Oracle Linux 5.5 オペレーティング・システムのインストールを自動的に実行しました。 kickstart を使用することで、クライアント・システムで迅速、効率的、かつ一貫性のあるオペレーティング・システムのインストールを実行できました。
kickstart の標準的な構成とインストールを採用しました(ネットワーク上の kickstart 中央サーバーをインストールに使用)。 Oracle Linux 5.5 の ISO イメージを、Dell の各拠点のイメージング・サーバーにコピーし、ネットワーク経由で使用できるようにしました。 kickstart オプションとインストール対象パッケージを指定する kickstart 構成ファイルを作成しました。 USB フラッシュ・ドライブを使用してクライアント・マシンをブートし、kickstart 構成ファイルをダウンロードしました。 インストールは、ユーザー操作なしで自動的に進められ、完了しました。
注意: インストール・プロセスによってバックアップ・ディスクが消去されないようにしてください。このディスクは、アーカイブしたシステム情報の保存に使用されます。 Dell の kickstart プロセスが影響したのは /dev/sda
ディスクだけで、/dev/sdb
には依然としてバックアップ情報を安全にアーカイブしたままにしてあります。
Dellは、Oracle Linuxへの移行時のインストール後プロセスの一部として、おもに次の手順を実行しました。
grub.conf
ファイルが異なるため、同等の SUSE Linux ファイルを直接コピーできませんでした。 代わりに次のように、適切な ioscheduler のエントリを新しい Oracle Linux /boot/grub/grub.conf
構成ファイルに次のように追加しました。 kernel KERNEL_PARAMETERS elevator=deadline
/etc/passwd
ファイルと /etc/shadow
ファイルに含まれる暗号化されたパスワード情報を直接コピーできませんでした。 代わりに、少数のローカル・ユーザー・アカウント(oracle
ユーザーなど)のパスワードを手動でリストアしました。ssh
のホスト鍵。 新しい Oracle Linux オペレーティング・システムをインストールした後、ssh
デーモンによって返されるホスト鍵が変更されました。 このため、ssh
クライアント・アクセスに必要な新しい known_hosts
鍵ファイルを、クラスタ内のホスト用に再生成しました。注: Dell は新しいクライアント鍵の生成を選択しましたが、バックアップから古いホスト鍵をリストアすることも可能です。
ifcfg-bondN
構成ファイル経由でボンディング・カーネル・モジュールが直接ロードされます。 一方、Oracle Linux ではボンディング・カーネル・モジュールとそのオプションのロードに /etc/modprobe.conf
ファイルが使用されます。 このため、ボンディング・カーネル・モジュールとその設定オプションをロードするため、新しい Oracle Linux の /etc/modprobe.conf
ファイルに次のようなエントリを追加しました。alias bond0 bonding options bond0 mode=active-backup miimon=100 downdelay=100 updelay=200
SUSE Linux と Oracle Linux ではいずれも、ネットワーク・デバイス情報が ifcfg-bondN
ファイルと ethN
ファイルに保存されます。 ただし、SUSE Linux ではこれらのファイルが /etc/sysconfig/network
ディレクトリに保存され、Oracle Linux では /etc/sysconfig/network-scripts
ディレクトリが使用されます。 以前の SUSE Linux 環境と新しい Oracle Linux 環境の両方の ifcfg-bondN
ファイルの例については、表3を参照してください。
ifcfg-bondN
ファイルの例 SUSE Linux | Oracle Linux |
---|---|
/etc/sysconfig/network/ifcfg-bond1 | /etc/sysconfig/network-scripts/ifcfg-bond0 |
DEVICE=bond1 BOOTPROTO='static' BROADCAST='192.168.255.255' IPADDR='192.168.0.190' NETMASK='255.255.0.0' NETWORK='192.168.0.0' REMOTE_IPADDR='' MTU='' STARTMODE='onboot' BONDING_MASTER='yes' BONDING_SLAVE_0='eth2' BONDING_SLAVE_1='eth3' BONDING_MODULE_OPTS='mode=active-backup miimon=100 downdelay=100 updelay=200' | DEVICE=bond0 BOOTPROTO=none ONBOOT=yes IPADDR='192.168.0.190' NETMASK=255.255.0.0 NETWORK=192.168.0.0 USERCTL=no |
以前の SUSE Linux 環境と新しい Oracle Linux 環境の両方の ifcfg-eth2
ファイルの例については、表4を参照してください。
ifcfg-eth2
ファイルの例 SUSE Linux | Oracle Linux |
---|---|
/etc/sysconfig/network/ifcfg-eth2 | /etc/sysconfig/network-scripts/ifcfg-eth2 |
DEVICE=eth2 STARTMODE='onboot' BOOTPROTO='none' MASTER='bond1' SLAVE='yes' | DEVICE=eth2 HWADDR=00:15:17:97:CD:4E BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no |
Oracle Linux システムでのネットワーク・ボンディングの設定について、詳しくは Oracle Linux システム管理のドキュメントを参照してください。
inittab
ファイルの Oracle 起動スクリプトの2つは例外でした。
.profile
ファイルが、Oracle Linux では .bash_profile
ファイルが使用されます。 このため、oracle
ユーザーと svcgrid
ユーザーの .profile
ファイルを、新しい Oracle Linux 環境の .bash_profile
ファイルにコピーしました。 inittab
ファイル。 inittab
ファイルは2つのオペレーティング・システムで異なります。 このため、(inittab
ファイルをそのまま直接コピーするのではなく)Oracle ソフトウェアの3つの起動スクリプトのエントリを新しい inittab
ファイルにコピーしました。 元のSUSE Linux inittab
ファイルの3つの関連する行(Event Manager デーモン(evmd
)、Oracle Cluster Services Synchronization デーモン(cssd
)、および Cluster Ready Services デーモン(crsd
)のエントリ)をアーカイブしたファイルからコピーして、新しい Oracle Linux inittab
ファイルの末尾に次のように追加しました。
注: 新しいオペレーティング・システムのインストール後に、オラクル製品の実行可能ファイルの再リンクが必要な場合があります。 詳しくは、My Oracle Supportの How to Relink Oracle Software on Unix [ID 131321.1] を参照してください(表示するには、有効なカスタマ・サポートID[CSI]が必要です)。
1,700台ものサーバーを SUSE Linux から Oracle Linux に移行することは、IT における非常にアグレッシブな決定でしたが、Dell がより優れた安定性とサポート、 容易な管理、およびコスト削減を実現するには必要でした。 アプリケーション・レイヤーはそのままにして、基盤となるオペレーティング・システム・レイヤーを 抽出して置き換えることは、Linux プラットフォームの標準規格があってこそ可能でした。 サイト固有のオペレーティング・システム構成の大部分は、単にバックアップして 新しいオペレーティング・システム上で直接リストアするだけでした。 同様に、Oracle Database やその他のアプリケーションも、若干の構成変更だけで SUSE Linux から Oracle Linux に移行できました。
2011年12月にこのドキュメントを作成した時点で、Dell は移行プロセスのほぼ中間点で、2012年6月に完了予定でした。 Dell の成功において重要な点は、移行開始前に慎重に計画し、必要なサイト固有の構成ファイルを項目化して、変換が必要なファイルを特定したことです。 実際の変換プロセスでは、スクリプトによる自動化と kickstart インストール、およびチェックリストを使って詳細に注意することにより、リスクを減らし、移行プロセス中の一貫性を保つことができました。
Dell は、SUSE Linux から Oracle Linux へのサーバー移行が、ビジネス上正しい決断であったと確信しています。 Dell の Enterprise Architect である Jon Senger は、次のようにコメントしています。「この困難だが魅力あるインフラストラクチャを使ってこれほど大規模な移行を行うのはリスクがありましたが、見事に報われました。 環境の TCO を節減できただけでなく、Oracle Linux での標準化によって、お客様の望む安定性とサポートを実現できました。」
Oracle Linux については、次のリソースを参照してください。
Oracle Linux のダウンロード:
Oracle Linux について: