SUSE Linux から Oracle Linuxへの移行方法( Dell のケース )


Jon Senger、Aik Zu Shyong、Suzanne Zorn 著

Dell の移行の計画および実装方法(変換上の主要な問題と、その移行プロセスの概要を含む)について説明します。



2012年1月公開
Dellロゴ
Oracleロゴ


たったひとつのサーバーでもオペレーティング・システムの切り替えは、簡単な問題ではありません。 関連する変換や互換性の問題の対応も同様です。 Dell のように、世界中に非常に多く展開しているサーバーの全オペレーティング・システムの切り替えに必要な作業を想像してみてください。

ソフトウェアのダウンロード、フォーラムへの参加、この記事のようなさまざまな技術的 How-To 資料へのアクセスをご希望の場合は、OTN メンバーにご登録ください。 スパム・メールが送信されることはありません。

Dell は、2010年6月にハードウェアおよびアプリケーション・レイヤーを変更せずに、1,700のシステムを SUSE Linux から Oracle Linux に移行することを決定いたしました。 Linux プラットフォームの持つ標準規格によって、この大規模なコンバージョンが可能になりました。 サイト固有のオペレーティング・システムやアプリケーションの構成の大部分は、単純にバックアップを取って新しいオペレーティング・システムに直接リストアを行う事で元の状態に戻す事が出来ています。 構成変更は最小限で、ほとんどが自動化出来、必要な管理作業も簡単で、信頼性の高い一貫した移行手順が可能でした。

Dell のデプロイメント環境

この移行プロセスの当初、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 が含まれていました。

Dell Linux の画像

図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 への移行を準備しました。

  1. スクラッチ領域を作成と、各種構成ファイルの保存。 Oracle Linux オペレーティング・システムとの互換性を維持するため、ReiserFS ファイル・システムではなく ext3 ファイル・システム(SUSE Linux 10 のデフォルト)を作成し、移行後に使用できるよう、このスクラッチ・ファイル・システムのロケーションを記録しました。 システム構成に応じて、接続されているファイバ・チャネル・ストレージ・デバイス上のスペア・ボリュームまたはマシン上のセカンダリ・ドライブを使用して ファイルを保存しました。

    特定のシステム構成では、スクラッチ領域のサイズが(バックアップが必要なデータの中で最大サイズの ORACLE_HOME ディレクトリに基づいて)異なっていました。このディレクトリと、バックアップが必要な各種システム構成ファイルの保持に十分な領域を確保しました。

  2. システム上のアプリケーションとサービスの停止。 init.d プロセスの無効化。 オラクルが推奨する停止順序に従って、Oracle Database、Oracle Automatic Storage Management、クラスタ・ノード上で実行されているアプリケーション、およびCluster Ready Services(CRS)を停止しました。 実行中のサービスを無効にするには、chkconfig コマンドを使用しています。
    # chkconfig service_name off
    
    

    Dell の移行では、移行対象システムのサービスの種類が停止手順に影響しました。 重要でないシステムでは、システム・メンテナンス期間をリクエストしてクラスタ全体を停止し、Oracle Linux に移行してから再起動しました。 ビジネス・クリティカルなアプリケーションを実行しているシステムでは、サービスの完全な停止は行っていません。 このような場合は、ローリング・アップグレードを採用しました。 選択したクラスタ・ノードから、クラスタ内の他のノードにサービスを移行し、選択したノードを Oracle Linux に移行しました。 次に、そのクラスタ・ノードを再起動してクラスタに再度追加しました。 クラスタ内のすべてのノードをアップグレードするまで、このプロセスを繰り返しました。

    : Oracle は異機種間の Oracle RAC クラスタをサポートしませんが、Dell のケースでは、Oracle Linux を実行しているノードと相互運用される SUSE Linux を実行しているノードの移行中に問題が発生することはありませんでした。 このような混在した OS 構成を使用したのは移行プロセス中のみで、通常のシステム運用では使用していません。
  3.  
  4. ファイル・システムが使用中でないことの確認。 lsofコマンドを使用して開いているファイルをリスト表示し、NFSマウントが使用中でないことを確認しました。 また、ORACLE_HOMEディレクトリがリソースで使用されていないことを確認しました。
    # lsof
    
  5. 関連するオペレーティング・システムの構成ファイルおよびディレクトリのアーカイブ。 表1を参照して、システム構成をアーカイブし、Oracle Linuxのインストール後にサイト固有の構成をリストアするために維持する必要があるオペレーティング・システム・ファイルのリストを収集しました。 まずサイト固有の構成ファイルを特定し、手順1で作成したスクラッチ・ロケーションにこれらのファイルをコピーするのに使用できるスクリプトを作成しまし た。

    : この表は参考用です。正確なファイルやファイル・ロケーションの正式なガイドではありません。 サイト固有の構成に基づいて、情報が変わる場合があります。

    表1:オペレーティング・システムの構成情報
    アーカイブ手順 コメント
    ハードウェア情報 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*
    追加のソフトウェア/アプリケーション オラクル以外のサード・パーティ製ソフトウェア・アプリケーションをバックアップ

  6. MPIO から PowerPath に変換。 Dell は、SUSE Linux の組込み MPIO サポートから EMC PowerPath に変換し、データ・パス管理を自動化することを選択しました。SUSE Linux 以外のシステムの場合、これが Dell の標準であるためです。 EMC PowerPath を使用したことで、変換後に LUN マッピングへのコピーも簡単になりました。

    MPIO から PowerPath への変換を実行するため、EMC によって記述されたカスタム・スクリプトがあります。 この変換手順の詳細は、ここでは説明しません。 データ・パス管理の変換について、詳しくは必要に応じて EMC またはそのストレージ・プロバイダにお問い合わせください。

  7.  
  8. Oracle 固有の構成情報のアーカイブ。 オペレーティング・システムの構成ファイルと同様に、接続されているファイバ・チャネル・ストレージ・デバイス上のスペア・ボリューム、またはマシン上の セカンダリ・ボリュームに、これらの Oracle 固有の構成ファイルを保存しました。 表2に、Oracle Linux への移行準備中に保存した Oracle 固有の構成ファイルを一覧表示しています。

    表2: Oracle 固有の構成
    アーカイブ手順 コメント
    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

  9. 最後に 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への移行時のインストール後プロセスの一部として、おもに次の手順を実行しました。

  1. SUSE Linux のオペレーティング・システムの構成ファイルを Oracle Linux にリストアおよび変換。 保存したオペレーティング・システムの構成情報(表1を参照)をリストアし、SUSE Linux から Oracle Linux に移行できるようにしました。 大部分の構成ファイルはバックアップ・コピーから直接リストアでき、変換は不要でした。 直接リストアしなかった設定は、次のとおりです。

    • Ioscheduler 情報。 Oracle Linux では grub.conf ファイルが異なるため、同等の SUSE Linux ファイルを直接コピーできませんでした。 代わりに次のように、適切な ioscheduler のエントリを新しい Oracle Linux /boot/grub/grub.conf 構成ファイルに次のように追加しました。

      kernel KERNEL_PARAMETERS elevator=deadline
            
    • パスワード情報。 暗号ハッシュ関数として、SUSE Linux 環境では Blowfish、新しい Oracle Linux 環境では MD5 を使用していたため、/etc/passwd ファイルと /etc/shadow ファイルに含まれる暗号化されたパスワード情報を直接コピーできませんでした。 代わりに、少数のローカル・ユーザー・アカウント(oracle ユーザーなど)のパスワードを手動でリストアしました。
       
    • sshのホスト鍵。 新しい Oracle Linux オペレーティング・システムをインストールした後、ssh デーモンによって返されるホスト鍵が変更されました。 このため、ssh クライアント・アクセスに必要な新しい known_hosts 鍵ファイルを、クラスタ内のホスト用に再生成しました。

      : Dell は新しいクライアント鍵の生成を選択しましたが、バックアップから古いホスト鍵をリストアすることも可能です。

    • ネットワーク・ボンディングの構成。 SUSE Linux では、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を参照してください。

      表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を参照してください。

      表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 システム管理のドキュメントを参照してください。

       

  2. Oracle 構成の設定およびファイルのリストア。 保存した Oracle 固有の構成情報(前の項の表2を 参照)をリストアし、SUSE Linux から Oracle Linux に移行できるようにしました。 オペレーティング・システムの構成ファイルと同様に、Oracle 固有の構成ファイルの大部分はバックアップ・コピーから直接リストアでき、変換は不要で した。 プロファイル・ファイルと inittab ファイルの Oracle 起動スクリプトの2つは例外でした。

     

    • プロファイル・ファイル。 SUSE Linux では .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 ファイルの末尾に次のように追加しました。

      # Run xdm in runlevel 5
      x:5:respawn:/etc/X11/prefdm -nodaemon
      h1:35:respawn:/etc/init.d/init.evmd run >/dev/null
      2>&1 </dev/null h2:35:respawn:/etc/init.d/init.cssd fatal
      >/dev/null 2>&1 </dev/null h3:35:respawn:/etc/init.d/init.crsd run >/dev/null
      2>&1 </dev/null

  3. サーバーを再起動。

  4. データベースの起動と動作確認。 サード・パーティ・ソフトウェア製品も同様に検証しました。

    : 新しいオペレーティング・システムのインストール後に、オラクル製品の実行可能ファイルの再リンクが必要な場合があります。 詳しくは、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 について:

FacebookTwitter、または Oracle Blogs で最新情報をご確認ください。