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

第 3 章 N1 Provisioning Server 3.1, Blades Edition 実行時の問題点

この章では、N1 Provisioning Server 3.1, Blades Edition 製品の実行に関する既知の問題点について説明します。

Control Center

この節では、N1 Provisioning Server の Control Center に関する既知の問題点について説明します。

Administration 画面のタイムアウトの問題点 (4849661)

Administration 画面から Editor 画面にナビゲートし、そのセッションがタイムアウトすると、Control Center にログインできなくなることがあります。

回避策: ブラウザを閉じて、別のブラウザを開き、もう一度ログインしてください。

Administration 画面にいるときに、そのセッションがタイムアウトした場合、もう一度ログインしたときに、ウィンドウが正しく表示されないことがあります。この現象が発生した場合、ブラウザを閉じて、もう一度ログインしてください。

セッションのタイムアウトを変更するには、/opt/terraspring/gw/war/WEB-INF/web.xml ファイルでタイムアウトの設定を変更します。 session-timeout タグを探します。値を分で指定します。

タイムアウト後、Find Farm ウィンドウが最大化する(4849673)

Find Farm セッションがタイムアウトした後、「Find Farm」ダイアログボックスで「Find」ボタンをクリックすると、「Find Farm」ウィンドウが最大化します。

回避策: タイムアウト値を増やします。つまり、/opt/terraspring/gw/war/WEB-INF ディレクトリにある web.xml ファイルのタイムアウト設定を変更します。 session-timeout タグを探します。値を分で指定します。

ファームの更新が失敗した後でロールバックしない (4849688)

ファームの更新が失敗したとき、変更がロールバックしない (つまり、ファームが更新前の良好な状態に戻らない) ことがあります。

回避策: この問題を回避するには、次のようにします。

エラー状態を解除するには、farm -pf farm-ID コマンドを使用して、当該ファームにアクセスします。
ファームエディタでそのファームを表示します。
ファームエディタの左側にある「Request History」パネルから、最新のファーム更新要求を選択します。正しいファーム情報が表示されます。
「File」メニューから「Commit」を選択して、ファームの更新を送信し直します。新たに更新された要求が発行されます。
新しい要求をブロック解除します。要求が完了した後、正しいファーム情報がファームエディタに表示されます。

ログインページにブックマークを設定できない (4849693)

開始画面以外のページにはブックマークを設定できません。

ダイアログページで情報をダウンロードする (4849697)

「Select: Disk Image」のようなダイアログページでは、アプリケーションはサーバーから情報をダウンロードする必要があります。ダウンロードが完了する前にページ上の任意のボタンをクリックすると、スクリプトエラーが発生します。

回避策: ページがすべての情報をサーバーからダウンロードし終わるまで、何もせずに待ちます。

新しいディスクを作成したとき、「Snapshot」ボタンが無効にならない (4849721)

サーバーグループを縮小して新しいディスクを作成したとき、無効になるはずの「Snapshot」ボタンが無効になりません。この「Snapshot」ボタンを押すと、エラーメッセージが表示されます。

Control Center からスナップショットまたはイメージを削除する (4856854)

Control Center からスナップショットまたはイメージを削除すると、削除されたというマークが付くだけです。 I-Fabric からは削除されません。 I-Fabric から削除するまで、削除されたというマークが付いたものと同じ名前のスナップショットまたはイメージは作成できません。

I-Fabric からスナップショットまたはイメージを削除するには、コントロールプレーンサーバーから image -lR コマンドを実行して、削除されたというマークが付いたイメージの一覧を表示します。次に、image -d コマンドを実行して、それらのイメージを I-Fabric から削除します。詳細は、image コマンドのマニュアルページを参照してください。

BOM に非管理デバイスが表示されない (4856865)

BOM (Bill Of Materials) ダイアログボックスに表示されるのは、N1 Provisioning Server が管理するデバイス (管理デバイス) に関する情報と、N1 Provisioning Server が管理しないデバイス (非管理デバイス) のうち、既知のタイプのデバイスに関する情報だけです。非管理デバイスのうち、未知のタイプのデバイスに関する情報は表示されません。

再読み込み操作後、グラフィックスが正しく表示されない (4857740)

現在のファームを再読み込みしたとき、ナビゲーションバー内のグラフィックスが正しく表示されません。

回避策: ページを再表示してください。

Control Center のクライアントソフトウェアの条件 (4857757)

Control Center には、128 ビットのセキュリティ暗号化を持つ Microsoft^TM Internet Explorer バージョン 6.0 Web ブラウザが必要です。

ファームを更新するときにポートを追加してもデバイスが切り替わらない (4989531)

まず、1 つのインタフェースだけが接続されているデバイスが要求および割り当てられます。その後、2 つのインタフェースが接続されているデバイスが要求されますが、割り当てられたデバイスにはインタフェースは 1 つしか接続されていないため、その要求は許可されません。したがって、この要求を満たす新しいデバイスは割り当てられません。

回避策 1: 2 つのインタフェースが必要なくても、常に、物理的なインタフェースを 2 つともサブネットに接続します。このように 2 番目のインタフェースを必ず接続することによって、デバイスは必ずファームに割り当てられます。一度認識させた後は、2 番目のインタフェースを構成し直すことができます。

回避策 2: サーバーの 2 番目のインタフェースを接続した後、リソース不足のためにファームの更新が失敗した場合、、ファームの設計を以前の設計に戻し、ファーム更新要求を発行し直して、ファームをアクティブな状態にします。ファームがアクティブな状態になった後、2 番目のインタフェースを追加したいデバイスのスナップショットを撮ります。スナップショットを撮った後、2 番目のインタフェースを追加したいオリジナルのサーバーを削除し、削除したサーバーを新しいサーバーに交換し、そのディスクをスナップショットのイメージから初期化して、ファームを更新します。新しいデバイスの物理的なインタフェースを 2 つともサブネットに接続して、ファーム更新要求を発行します。これで、2 つのインタフェースが接続された新しいサーバーがファームに割り当てられます。

回避策 3: 2 番目の接続が必要なデバイスをホストしているシャーシに 2 番目のスイッチを追加します。 shelfsync コマンドを使用して、デバイスを更新します。次に、ファーム更新要求を再発行します。

回避策 4: サーバーの2 番目のインタフェースを使用する代わりに、1 番目のインタフェース上の仮想インタフェースを使用してファームを更新します。この回避策では、1 番目のインタフェースの帯域幅を eth0 と仮想インタフェースで共有します。

インポートしたファームのポートの数が間違っている (4998397)

インポートしたファームのタイプは適切ですが、関連する接続の数が間違っていることがあります。

回避策: .feml ファイルからファームの設計をインポートしたときには、デバイスのタイプが現在の I-Fabric に記録されているものと一致するかどうかを確認します。特に、各デバイスのポートの数が正しいかどうかを確認します。デバイスのポートの数が正しくない場合、新しい設計を発行する前に、デバイス構成ダイアログボックスでデバイスのタイプを変更します。

PostgresSQLでファーム要求をブロック解除しようとすると、間違ったエラーメッセージが表示される (5002047)

Pending 要求ページからファーム要求をブロック解除しようとすると、次のエラーメッセージが表示されます。

Operation failed... may have been caused by ifabric misconfiguration

回避策: もう一度その要求を実行します。何回か実行すれば、成功することがあります。

サーバー管理の問題点

この節では、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 のプロセスをすべて停止してください。

次のコマンドを実行して、残っている Farm Manager のプロセスをチェックします。
/usr/ucb/ps -auxwww | grep -i “com.terraspring.cs.fm”
UNIX^TM の 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 を定義しており、これらのポリシーを変更したい場合は、次の手順に従います。

ポリシーを変更する仮想 IP を削除して、要求を発行します。
そのポリシーを希望のポリシーに変更します。
仮想 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 つの更新で行う必要があります。次の手順に従います。

x86 サーバーが 1 台だけのファームを Control Center (CC) からアクティブ化します。たとえば、このファームは名前が「Server1」で、eth0 でサブネットに接続されていると仮定します。
このファームをアクティブ化した後、CC にログオンして、x86 サーバーを削除します。
この変更をコミットするようにファームを発行します。
名前が同じ (「Server1」) SPARC 版の Solaris サーバーを追加します。
CC から変更をコミットします (つまり、更新要求を送信します)。

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

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

回避策: ありません。

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

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

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

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

次のコマンドを入力して、アクティブなファームの一覧を取得します。 farm -l
状態が CREATED 以外のファームごとに、次のコマンドを入力して、イメージが使用中であるかどうかを判断します。 lr -lv fmid | grep Image

ここで、fmid は手順 1 で取得したファーム ID です。
状態が 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 の範囲外で行われます。

images ファイルシステムが何らかの目的で使用されており、N1 Provisioning Server 以外のソフトウェアで作成したファイルを images ファイルシステムにコピーした場合、イメージリポジトリの実際のサイズは減ります。しかし、データベース内のサイズの値はイメージリポジトリのサイズの減少を反映しません。

この場合、N1 Provisioning Server ソフトウェアは十分なディスク容量があると想定しているので、スナップショット操作を許可します。しかし、images ファイルシステム上の実際のディスク容量は十分でないため、スナップショット操作は失敗します。
パーティションを拡張するときに、オリジナルのパーティションを二次ディスク上の新しいパーティションで置き換えたり、N1 Provisioning Server ソフトウェアが認識できないファイルを images ファイルシステムから削除した場合、images ファイルシステムの実際のサイズは増えます。しかし、データベース内のサイズの値はイメージリポジトリのサイズの増加を反映しません。

この場合、ファイルシステムに十分なディスク容量があっても、N1 Provisioning Server ソフトウェアはディスク容量が不足していると想定しているので、スナップショット操作を許可しません。この場合、障害が発生するのは、スナップショットデータがコピーされる前または後の両方の可能性があります

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

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

次のコマンドを使用して、イメージサーバーのデバイス ID を調べます。
# /opt/terraspring/sbin/device -Lr
次のコマンドを使用して、N1 Provisioning Server データベース内のイメージリポジトリのサイズを調べます。
# /opt/terraspring/sbin/device lv device-id | grep imsvsize
ここで、device-id は前の手順で調べたデバイス ID です。
N1 Provisioning Server リポジトリが認識しているすべてのイメージの合計サイズを求めます。
1. すべてのイメージの詳細な一覧を取得するには、次のコマンドを入力します。
  # image -lv > tmpfile
2. tmpfile を調べて、各イメージの「Image Locations」セクションにあるサイズの値をすべて記録します。
3. 前の手順で記録した値をすべて足して、N1 Provisioning Server リポジトリが認識しているすべてのイメージの合計サイズを求めます。
前の 2 つの手順で求めた値を引いて、N1 Provisioning Server ソフトウェアがイメージサーバーで利用できると認識しているディスク容量の合計を求めます。
次のコマンドを使用して、実際のファイルシステムのサイズを調べます。
# df -k path-to-images-filesystem
実際のファイルシステムで利用できるディスク容量 (バイト数) を求めるには、 df の出力の「avail」の下にある値に 1024 をかけます。

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

手順 6 で求めた実際のサイズに手順 3c で求めたイメージの合計サイズを足します。この合計は、N1 Provisioning Server リポジトリ内の imsvsize 属性の新しい値になります。
次のコマンドを使用して、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 つを行う必要があります。

問題のあるブレードを交換します。このブレードには問題があるため、できるだけ早く交換する必要があります。次の手順に従います。
1. 次のコマンドを入力して、メッセージ内の device-id が示すブレードのプロパティを表示します。
  # /opt/terraspring/sbin/device -l device-id
2. FARM_ID 列を調べます。
  
  FARM_ID 列にハイフン (-) が含まれない場合、そのブレードはファームの一部です。
  
  ブレードがファームの一部である場合、次のコマンドを入力して、問題のあるブレードを同じような属性を持つ別のブレードと交換します。
  # /opt/terraspring/sbin/replacedevice farm-id failed-device-id
3. 当該ブレードが格納されているシェルフの ID を調べるには、次のコマンドを入力します。
  # /opt/terraspring/sbin/device -l device-id
  次のような行を探します。
  cpu:sun-b100s-blade (- -) 50100:s0 ==> pwr:sun-b1600-pwr (- -) 50160:s0
  この例では、シェルフのデバイス ID は 50160 です。
4. シェルフの IP アドレスを調べるには、次のコマンドを入力します。
  # /opt/terraspring/sbin/device -lv shelf-device-id
  ipaddress: というフィールドを探して、シェルフの IP アドレスを取得します。
5. シェルフに telnet 接続し、次のコマンドを入力して、そのブレードを削除する準備をするようにシェルフコントローラに通知します。
  # replacefru Sn
  このコマンドに応答して、ブレード上の青い LED が点灯します。
6. ブレードシェルフのフロントパネルから問題のあるブレードを取り外します。
  
  欠陥のあるブレードには青い LED が点灯しているため、シェルフ内のほかのブレードと区別できます。
7. 代わりの正常なブレードをブレードシェルフに取り付けます。
8. 新しいブレードを検出し、データベース内の情報を更新するには、次のコマンドを入力します。
  # /opt/terraspring/sbin/shelfsync
9. ブレードをテストするには、次のコマンドを入力します。
  # /opt/terraspring/sbin/pestest
ブレードに FAILED というマークを付けます。問題のあるブレードを交換しない場合、そのブレードに FAILED というマークを付ける必要があります。そうしないと、ファーム内で問題のあるブレードが使用され、ファームのアクティブ化が失敗することがあります。次の手順に従います。
1. 次のコマンドを入力して、ブレードのプロパティを表示します。
  # /opt/terraspring/sbin/device -l device-id
2. FARM_ID 列を調べます。
  
  FARM_ID 列にハイフン (-) が含まれない場合、そのブレードはファームの一部です。
  
  次のコマンドを入力して、問題のあるブレードを同じような属性を持つ別のブレードと交換します。
  # /opt/terraspring/sbin/replacedevice farm-id failed-device-id
3. STATE 列を調べます。
  
  STATE が FAILED に設定されていない場合、次のコマンドを入力して、STATE を FAILED に設定します。
  # /opt/terraspring/sbin/device -sB device-id

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

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

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

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

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

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

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

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

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

同時にサポートできるのは 1 つのプロトコル (FTP または NFS) だけです。したがって、FTP サポートが有効になっている N1 データセンターでは、現在のところ、プロビジョンやスナップショットは FTP 経由でだけ実行できます。
フラッシュイメージと JumpStart イメージは FTP を有効にした N1 データセンターではサポートできません。結果として、フラッシュイメージと JumpStart イメージはすべて削除する必要があります。
FTP を有効にした N1 データセンターでフラッシュまたは JumpStart のスナップショットを実行しようとすると、エラーが発生して、未知の方法で異常終了します。このような操作はサポートされません。
フラッシュまたは JumpStart のプロビジョンを実行すると、一応機能しますが、これはサポートされません。

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

手順

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

イメージサーバのデバイス 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.

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

# /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
...

プロトコル属性を FTP に変更するには、次のコマンドを入力します。
# /opt/terraspring/sbin/device -sA protocol ftp image-server-device-id

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

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

次の例では、ユーザー名は n1psftpu、パスワードは n1psftpp に設定しています。
# useradd n1psftpu # passwd n1psftpu New Password: Re-enter new Password: passwd: password successfully changed for n1psftpu

パスワードを暗号化するには、次のコマンドを入力します。
# /opt/terraspring/sbin/encrypter password
次の例の出力を参照してください。
# encrypter n1psftpp ptMSB/T9fNm8Borrjxl/gw==

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

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

# /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

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

次の手順に従います。

イメージファイルが削除されないように、イメージサーバー上でイメージファイルの名前を一時的な名前に変更しておきます。
# mv /images/master-images/rh-linux-i86pc-disk-img \ /images/master-images/rh-linux-i86pc-disk-img.bak

データベース内のイメージ情報から 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

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

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

イメージデータベースに 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

FTP URL の状態を更新するには、コマンド /opt/terraspring/sbin/imagesync --nosync image-id を入力します。
# /opt/terraspring/sbin/imagesync --nosync 1 Image 1 forcibly marked as synchronized

次のコマンドを入力して、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

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

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