test

N1 Provisioning Server 3.1, Blades Edition ご使用にあたって

サーバー管理の問題点

この節では、N1 Provisioning Server 3.1, Blades Edition サーバーの管理に関する既知の問題点について説明します。

ディスクコピー操作中に障害が発生したとき (4849694)

ファームがスタンバイモードに移行するときには、そのファームに属するすべてのサーバーのディスクコピー操作が同時に開始します。 しかし、最初のディスクコピー操作中に障害 (ディスク容量が足りないなど) が発生した場合、以降のディスクコピー操作がすべて完了するまで、最初の障害は報告されません。

回避策: ありません。

Control Plane データベースに利用可能なサーバーが存在しない場合に「No More Resources」例外が発生する (4849699)

Control Plane データベースに利用可能なプロビジョニングサーバーが存在しない場合、単一のファーム操作では、あるサーバーグループから別のサーバーグループにサーバーを移動できません。

回避策: まず、1 番目のサーバーグループから当該サーバーを削除して、そのファームを更新します。 次に、そのサーバーを 2 番目のサーバーグループに追加して、そのファームを更新します。

注 –

1 番目のサーバーグループから削除して 2 番目のサーバーグループに追加するまでの間、そのサーバーはほかのファームが提供することがあります。 この場合は「No More Resources」例外が発生します。

mls コマンドが正確な状態を表示しない (4849719)

mls -a コマンドは、DOWN というマークが付いているサーバー上の エージェントを正しく報告しないことがあります。

回避策: 60 秒だけ待って、もう一度ノードの状態を確認してみてください。 コントロールプレーンサーバーによる通常のノードの監視はこの状況の影響を受けず、問題のあるノードを正確に報告します。

非管理デバイスがファームの VLAN に移動できない (4856867)

通常、ベンチ構成後、シェルフ上のポートは中継モードです。 この構成では、非管理デバイスをファーム VLAN に移動できません。

回避策: 非管理デバイスのポートを中継モードからハイブリッドモードに変更します。 次に、非管理デバイスを VLAN に追加します。

コントロールプレーンサーバーを停止する前にアクティブな要求を削除する (4856872)

コントロールプレーンサーバーを停止する前には、アクティブな要求がシステムに残っていないことを確認してください。 コントロールプレーンサーバーに障害が発生すると、残っている Farm Manager のプロセスが正常に終了しません。 コントロールプレーンサーバーを再起動する前に、次の手順を実行して、残っている Farm Manager のプロセスをすべて停止してください。

  1. 次のコマンドを実行して、残っている Farm Manager のプロセスをチェックします。 


    /usr/ucb/ps -auxwww | grep -i “com.terraspring.cs.fm”

  2. UNIXTM の kill コマンドを使用して、残っている Farm Manager のプロセスを停止します。

power コマンドの問題点 (4857749)

power コマンドに -off オプションを指定すると、UNIX の poweroff コマンド (コマンドが発行されたデバイスの電源を切断する) に似ています。 power コマンドに -off オプションを指定するときには、power と -off の間に空白を入れるのを忘れないでください。空白を入れなければ、コントロールプレーンサーバーの電源を切断してしまいます。

既存のファームで使用されるプロビジョニングサーバーの電源の状態を変更する (4919199)

既存のファームで使用されるプロビジョニングサーバーの電源は個別に投入または切断してはなりません。

Gigabit Ethernet カードのインスタンスの割り当て (4924060)

プロビジョニングサーバーマシンの Gigabit Ethernet カードには、インスタンス 0 を割り当てる必要があります。

負荷均衡ポリシーを変更しただけではロードバランサの構成は更新されない (4998087)

アクティブなファームの負荷均衡ポリシーを変更した場合 (たとえば、round-robin から wt-round-robin に変更した場合)、そのファームは更新プロセスに入ります。 しかし、そのプロセスが完了した後でも、ロードバランサの構成は元のポリシーのままです (たとえば、round-robin のまま)。

回避策: すでに仮想 IP を定義しており、これらのポリシーを変更したい場合は、次の手順に従います。

  1. ポリシーを変更する仮想 IP を削除して、要求を発行します。

  2. そのポリシーを希望のポリシーに変更します。

  3. 仮想 IP を作成し直して、要求を発行します。

存在しない 2 番目のスイッチ (eth1) を構成しようとしてロードバランサが失敗する (4998088)

1 番目のスイッチ (ssc0) しかないシャーシにロードバランサがインストールされている場合、そのロードバランサは 2 番目のスイッチ (eth1) も構成しようとします。

回避策: このリリースのロードバランサはデュアルスイッチのシェルフしかサポートしません。

ロケータ URL を更新するときにエラーメッセージが表示される (5002040)

既存のスナップショットイメージのロケータ URL をコマンド image -u -l で更新しようとすると、エラーメッセージが表示されます。 このとき表示されるエラーメッセージは、データベースが Oracle であるか PostgresSQL であるかによって異なります。

Oracle の場合、表示されるメッセージは次のとおりです。 


Locator URL 'nfs://3001//images/master-images/solaris9u5-i86pc-flash' already exists!

PostgresSQL の場合、表示されるメッセージは次のとおりです。 


ERROR: duplicate key violates unique constraint "imglocator_unique"

回避策: ありません。 これは表面上のバグであり、将来のリリースで修正される予定です。

タイプは異なるが名前が同じデバイスに交換するとエラーが発生する (5002041)

アクティブなサーバーファームで特定のタイプのデバイスを定義していると仮定します (たとえば、「Server1」という名前を持つ x86 ファーム)。 このとき、名前はそのままで、タイプを「sparc」に変更します。 新しいデバイスを追加する前に削除要求のコミットに失敗した場合、追加要求も失敗して、このファームには同じ名前のデバイスがすでに存在しているという制約例外が発生します。

回避策: 削除と追加は異なる 2 つの更新で行う必要があります。 次の手順に従います。

  1. x86 サーバーが 1 台だけのファームを Control Center (CC) からアクティブ化します。 たとえば、このファームは名前が「Server1」で、eth0 でサブネットに接続されていると仮定します。

  2. このファームをアクティブ化した後、CC にログオンして、x86 サーバーを削除します。

  3. この変更をコミットするようにファームを発行します。

  4. 名前が同じ (「Server1」) SPARC 版の Solaris サーバーを追加します。

  5. CC から変更をコミットします (つまり、更新要求を送信します)。

PostgresSQL データベース restoredb に対して backupdb を実行すると無効なデータが作成される (5002042)

PostgresSQL データベースを使用しているときに backupdb を実行すると、無効なバックアップデータが生成されます。 結果として、バックアップデータが無効であるため、restoredb は失敗します。

回避策: ありません。

image コマンドはイメージが使用中であるかどうかをチェックしない (4892852 と 5002045)

image コマンドは、イメージが使用中の場合でも、イメージを削除 (image -d) または変更 (image -u) できます。 しかし、イメージが使用中の場合、この変更を Control Center と同期をとろうとすると失敗します。

回避策 1: Control Center を使用して、イメージを削除または変更します。

回避策 2: image コマンドを使用する前に、イメージが使用中でないことを確認します。 イメージが使用中であるかどうかを確認するには、次の手順に従います。

  1. 次のコマンドを入力して、アクティブなファームの一覧を取得します。 farm -l

  2. 状態が CREATED 以外のファームごとに、次のコマンドを入力して、イメージが使用中であるかどうかを判断します。 lr -lv fmid | grep Image

    ここで、fmid は手順 1 で取得したファーム ID です。

  3. 状態が CREATED のファームごとに、次のコマンドを入力して、その FML を取得し、一時ファイルに保存します。 farm -lv fmid > /tmp/fmlfmid

    一時ファイルを調べて、文字列 <diskimage を含む行をすべて探します。 その次の行にイメージ ID があります (次を参照)。 

    <disk id="10" location="internal" name="Disk B" size="30000000000" type="local">
<diskimage type="system">
 6
</diskimage>
<client-info id="11" object-id="10">

手順 2 から 3 で見つかったイメージ ID は、現在そのイメージが使用中であることを示します。

image -d で存在しないイメージを削除すると Java 例外が発生する (5002046)

存在しないイメージ ID を指定してコマンド image -d を実行すると、Java 例外が発生します。

回避策: 正しいイメージを指定して、もう一度コマンドを実行します。

アップグレードすると incompatible class 例外が発生する (5002048)

N1 Provisioning Server 3.0 Blades Edition, Update 1 から N1 Provisioning Server 3.1, Blades Edition にアップグレードした後、コマンド request -lv を実行すると、以前のバージョンで作成した要求で実行時例外が発生することがあります。

回避策: ありません。 アップグレードする前に発行された要求の詳細は表示できません。

イメージウィザードでアカウントイメージを削除すると Java 例外が発生する (5002051)

イメージウィザードを使用してアカウントイメージを削除すると、Java 例外が発生します。

回避策: 次のコマンドを使用して、アカウントイメージを削除します。 image -d image-id

待ち行列に入っている replacePhysicalDevice 要求のためにイメージウィザードが実行を停止する (5002052)

イメージウィザードの指示に従ってサーバーをシャットダウンすると、replacePhysicalDevice 要求が待ち行列に入っている (QUEUED 状態である) ことがあります。 イメージウィザードは、この要求を削除するように知らせません。 QUEUED 状態の要求を削除しなかった場合、replacePhysicalDevice 要求が snapshot 要求の実行をブロックするため、イメージプロセスを継続できません。

回避策: replacePhysicalDevice 要求を削除します。

十分なディスク容量があるにもかかわらず、image コマンドが新しいイメージの作成に失敗して「Insufficient Disk Space」というエラーメッセージを表示する (4989527)

イメージサーバーのサイズは、インストール中、ファイルシステムに問い合わせることによって決定されます。 このサイズは、イメージサーバーデバイスの属性としてデータベース内に記録されます。 この値は静的であり、N1 Provisioning Server の範囲外のファイルシステムで行われた変更は反映しません。 次の変更は N1 Provisioning Server の範囲外で行われます。

どちらの場合も、原因を示す兆候は現れません。 表示されるエラーだけでは、問題の原因がデータベース内のイメージサーバーのサイズの間違いであるかどうかは分かりません。 このエラーは /var/adm/tspr.debug ログファイルに記録されることもあります。

回避策: 原因不明のスナップショットエラーが表示された場合、次の手順に従って、問題の原因がデータベースと実際のファイルシステム間のサイズの不一致であるかどうかを判断します。

  1. 次のコマンドを使用して、イメージサーバーのデバイス ID を調べます。 


    # /opt/terraspring/sbin/device -Lr

  2. 次のコマンドを使用して、N1 Provisioning Server データベース内のイメージリポジトリのサイズを調べます。 


    # /opt/terraspring/sbin/device lv device-id | grep imsvsize

    ここで、device-id は前の手順で調べたデバイス ID です。

  3. N1 Provisioning Server リポジトリが認識しているすべてのイメージの合計サイズを求めます。

    1. すべてのイメージの詳細な一覧を取得するには、次のコマンドを入力します。 


      # image -lv > tmpfile

    2. tmpfile を調べて、各イメージの「Image Locations」セクションにあるサイズの値をすべて記録します。

    3. 前の手順で記録した値をすべて足して、N1 Provisioning Server リポジトリが認識しているすべてのイメージの合計サイズを求めます。

  4. 前の 2 つの手順で求めた値を引いて、N1 Provisioning Server ソフトウェアがイメージサーバーで利用できると認識しているディスク容量の合計を求めます。

  5. 次のコマンドを使用して、実際のファイルシステムのサイズを調べます。 


    # df -k path-to-images-filesystem

  6. 実際のファイルシステムで利用できるディスク容量 (バイト数) を求めるには、 df の出力の「avail」の下にある値に 1024 をかけます。

手順 4 の値 (見かけのサイズ) が手順 6 の値 (実際のサイズ) と異なる場合、サイズの不一致が存在します。 この不一致を解消するには、次の手順に従います。

  1. 手順 6 で求めた実際のサイズに手順 3c で求めたイメージの合計サイズを足します。 この合計は、N1 Provisioning Server リポジトリ内の imsvsize 属性の新しい値になります。

  2. 次のコマンドを使用して、N1 Provisioning Server データベースの lmsvsize 属性を、前の手順で求めた新しい値に更新します。 


    # device -sA imsvsize new-imsvsize-value device-id

2 つのファームを同時にアクティブ化すると失敗する (4989529)

新たにインストールしたデータセンターに 2 つのファームを同時に作成すると、どちらか一方のファームに障害が発生して、次のエラーメッセージが表示されることがあります。 


[MSG8300 ] Sql Error::ORA-00955: name is already used by an existing object

回避策: Control Center からそのファームを発行し直します。

farm -Lt がログの末尾を表示しない (4997346)

PostgresSQL データベースが動作している N1 Provisioning Server 3.1, Blades Edition インストールでは、コマンド farm -Lt farm-id がログの出力を停止することがあります。

回避策: ログの tail プロセスを強制終了して、実行し直します。

SC が重要でない障害を報告しただけで N1 Provisioning Server はそのブレードを Failed または Unusable として分類する(4998378)

pestest が動作しているインストール中、あるいは、ファームをアクティブ化しているときの実行時、次のようなメッセージが画面またはデバッグログに出力されることがあります。 


device-id: test FAILED: Reason was:  - Cannot save state information for device-id: Blade Sn seems to be faulty

回避策: 後者 (ファームをアクティブ化しているとき) の問題を回避するには、次のうちの 1 つを行う必要があります。

スナップショットが失敗すると dhcpd.conf 構成ファイル内に情報が残る (4998415)

スナップショットが失敗した後は、ファームのアクティブ化または更新も失敗します。

回避策: /etc/dhcpd.conf ファイルの image-copy-subnet セクションからファームの構成情報を削除します。 次に、サーバーをリブートし、ファームをアクティブ化し直して、スナップショットの前の状態に戻します。

shelfsync がすでに存在する B10n ブレードを追加しようとする (5006442)

Sun Fire B10n ブレードは高可用性負荷均衡ペアの一部にすることができます。 言い換えると、このデバイスは論理デバイスの子デバイスであり、そのタイプはデバイスタイプ halb のサブタイプです。 当該ブレードを格納しているシェルフ上で shelfsync コマンドを実行すると、そのデバイスは新たに検出されたデバイスであると報告されます。 次に、この新しいデバイスを追加することを選択した場合、そのデバイスをデータベースに追加する途中で、あるメッセージが表示されます。 つまり、同じ MAC アドレスを持つデバイスがすでにデータベースに存在するというメッセージです。

回避策: このメッセージは無視してください。

FTP イメージと FTP イメージサーバーのサポートが明確でない (5003423)

N1 Provisioning Server 3.1, Blades Edition 製品では、フラッシュイメージと JumpStart イメージをサポートする必要があるため、FTP イメージとFTP イメージサーバーのサポートは無効になっています。

回避策: FTP サポートは有効にできます。 しかし、次の注意点に気をつける必要があります。

ProcedureN1 データセンターで FTP を有効にするには

手順

  1. 上記注意点によく気を付けます。

  2. イメージサーバのデバイス ID を調べるには、次のコマンドを入力します。 


    # /opt/terraspring/sbin/device -Lr is

    次の例では、デバイス ID は 3001 です。 


    # /opt/terraspring/sbin/device -Lr is
 DEVICE_ID  PARENT_ID STATUS   FARM_ID    TYPE
      3001          - USED     -          cpu:sun-svr-420R-idb (Sun 420R)
1 devices found.

  3. イメージサーバーが使用している現在のプロトコルを確認するには、次のコマンドを入力します。 


    # /opt/terraspring/sbin/device -lv image-server-device-id

    次の例では、プロトコルは nfs です。 


    # /opt/terraspring/sbin/device -lv 3001
Device ID: 3001, state: USED, owner: -, type: cpu:sun-svr-420R-idb (Sun 420R)
  Device Attributes:
    make:           Sun
    name:           ps1
    imsvsize:       67372343296
    halclass:       com.terraspring.drivers.sun.SunSysKonnect
    nicvips:        1000
    role:           ispdb
    model:          420R
    basepath:       /images
    compressionratio:8
    protocol:       nfs
...

  4. プロトコル属性を FTP に変更するには、次のコマンドを入力します。 


    # /opt/terraspring/sbin/device -sA protocol ftp image-server-device-id

  5. FTP 経由でイメージサーバーに接続するときに使用するユーザー名とパスワードを決定します。

    このユーザー名とパスワードは新規に作成してもかまいません。

    次の例では、ユーザー名は n1psftpu、パスワードは n1psftpp に設定しています。 


    # useradd n1psftpu
# passwd n1psftpu
New Password:
Re-enter new Password:
passwd: password successfully changed for n1psftpu

  6. パスワードを暗号化するには、次のコマンドを入力します。 


    # /opt/terraspring/sbin/encrypter password

    次の例の出力を参照してください。 


    # encrypter n1psftpp
ptMSB/T9fNm8Borrjxl/gw==

  7. ftp_user 属性と ftp_password 属性をデータベース内のイメージサーバーデバイスに追加するには、属性ごとに 1 回ずつ、次のコマンドを入力します。 


    # /opt/terraspring/sbin/device -sA attribute-name attribute-value image-server-device-id

    次の例のように、暗号化したパスワードは ftp_password 属性の値として使用する必要があります。 


    # /opt/terraspring/sbin/device -sA ftp_user n1psftpu 3001
# /opt/terraspring/sbin/device -sA ftp_password 'ptMSB/T9fNm8Borrjxl/gw==' 3001
    ヒント –

    変更を確認するには、次のコマンドを入力します。 


    # /opt/terraspring/sbin/device -lv image-server-device-id

  8. ディスクイメージやほかのイメージの一覧を表示するには、次のコマンドを入力します。 


    # /opt/terraspring/sbin/image -l

    次の例では、 2 つのイメージが表示されています。 


    # /opt/terraspring/sbin/image -l
IMAGE_ID IMAGE_NAME               CUSTOMER         SIZE       OS           TYPE            \
STATE     LOCATION
1        rh-linux-i86pc-disk-img  __grid__         30000000000 linux       disk_image      \
READY     nfs://3001//images/master-images/rh-linux-i86pc-disk-img
6        solaris9u5-i86pc-flash   __grid__         1500000000 solaris      flash           \
READY     nfs://3001//images/master-images/solaris9u5-i86pc-flash

  9. ディスクイメージごとに、URL 内のプロトコルを FTP に変更します。

    次の手順に従います。

    1. イメージファイルが削除されないように、イメージサーバー上でイメージファイルの名前を一時的な名前に変更しておきます。 


      # mv /images/master-images/rh-linux-i86pc-disk-img   \
/images/master-images/rh-linux-i86pc-disk-img.bak

    2. データベース内のイメージ情報から NFS URL を削除するには、コマンド /opt/terraspring/sbin/image -dL nfs-url image-id を入力します。 


      # /opt/terraspring/sbin/image -dL   \
nfs://3001//images/master-images/rh-linux-i86pc-disk-img 1
    Image id is: 1
    Delete URL nfs://3001//images/master-images/rh-linux-i86pc-disk-img for this image (y/n)? y
    Deleting image content at: nfs://3001//images/master-images/rh-linux-i86pc-disk-img   \
size: 1532913330   ip: 10.52.53.1   State: done
    Deleted locator URL: nfs://3001//images/master-images/rh-linux-i86pc-disk-img

    3. イメージサーバー上でイメージファイルの名前を元に戻します。 


      # mv /images/master-images/rh-linux-i86pc-disk-img.bak   \
/images/master-images/rh-linux-i86pc-disk-img

    4. イメージデータベースに FTP URL を追加するには、コマンド /opt/terraspring/sbin/image -uL ftp-url image-id を入力します。

      注 –

      FTP URL は NFS URL とほとんど同じ URL で、唯一、プロトコル 部分だけを ftp に変更します。 


      # /opt/terraspring/sbin/image -uL \
ftp://3001//images/master-images/rh-linux-i86pc-disk-img 1
    Updated image: 1

    5. FTP URL の状態を更新するには、コマンド /opt/terraspring/sbin/imagesync --nosync image-id を入力します。 


      # /opt/terraspring/sbin/imagesync --nosync 1
    Image 1  forcibly marked as synchronized

    6. 次のコマンドを入力して、URL 内のプロトコルが実際に ftp に変更されていることを確認します。 


      # /opt/terraspring/sbin/image -lv image-id

      以下に例を示します。 


      # /opt/terraspring/sbin/image -lv 1
IMAGE_ID IMAGE_NAME               CUSTOMER         SIZE       OS           TYPE            \
STATE     LOCATION
1        rh-linux-i86pc-disk-img  __grid__         30000000000 linux       disk_image      \
READY     ftp://3001//images/master-images/rh-linux-i86pc-disk-img

Description:   RedHat Linux 2.1 AS, disk image, with snet NIC
Architecture:  i86pc
Last Updated:  2004-02-12 23:19:01.0

Image Locations:
    ID    STATE     SIZE             LOCATION
    26    done      1532913330       ftp://3001//images/master-images/rh-linux-i86pc-disk-img

  10. フラッシュイメージまたは JumpStart イメージごとに、次のコマンドを入力して、これらのイメージを削除します。 


    # /opt/terraspring/sbin/image -d image-id
    注 –

    フラッシュイメージまたは JumpStart イメージを削除する前には、どのイメージも使用中でないことを確認します (「image コマンドはイメージが使用中であるかどうかをチェックしない (4892852 と 5002045)」を参照)。 イメージが使用中の場合、イメージを削除する前に、イメージを使用しているファームを非アクティブ化して削除します。 このようにしない場合、将来、これらのイメージが配備されているサーバーディスクのスナップショットを撮るとき、Control Center がフラッシュスナップショットを許可するように見えても、disk_image として撮る必要があることを覚えておいてください。 ここまでの注意点を参照してください。 


    # /opt/terraspring/sbin/image -d 6
Delete Image 6 (y/n)? y
Queueing request to delete image ...
Request (id: 74) submitted.
Waiting for request 74 to complete...
.
Deleting image content at: nfs://3001//images/master-images/solaris9u5-i86pc-flash   
size: 647191212   ip: 10.52.53.1   State: done

    これで、データセンター内のイメージのプロビジョンおよびスナップショットの両方に対して、FTP プロトコルは有効になっています。