- Cloud 環境 -
- AWS インスタンスストレージ (エフェメラルストレージ/ディスク) を適切に使う
- AWS サーバー上に SIOS AMIs がデプロイされていない場合は、これらのディスクの初期化処置を検討する必要があります。これは Windows 2016 から導入され、以降のリリースでも継続されています。
- AWS エフェメラルストレージ (インスタンスストア) は、ノードが “完全な” シャットダウン (リブートではなく、AWS コンソールもしくは Windows の CLI “shutdown /s” からシャットダウンを行うこと。) から起動する度に初期化する必要があります。
- Windows 2012 R2 は自動的にこの処置を実行 (Ec2Config サービスにより) します。AWS はこの初期化を実行するスクリプト (EC2Launch) を含んでいますが、そのスクリプトはユーザーにより手動でスケジュールする必要があり、その結果ブート時に実行されます。
- AWS 上の SIOS AMIs は、このタスクを自動的に設定します。AWS であなた自身の Windows イメージを展開していてブート時に実行するスクリプトの設定に失敗し、さらに (ベストプラクティス で推奨されているように) ビットマップにエフェメラルストレージを使用している場合は、ビットマップファイル/ボリュームが失われ、DataKeeper ミラーは再作成されません。
解決策
- Disk Management を起動し、エフェメラルストレージがオンライン、正常で、エフェメラルストレージに対して選択したボリュームレターが割り当てられていることを確認する。
- エフェメラルストレージにアサインされたドライブ/ドライブレターが HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExtMirr\Parameters . . . BitmapBaseDir に配置されているレジストリに記載されていることを確認する。
注意: この解決策をクラスターの全ノードに適用してください。
長期的な解決策
EC2Launch スクリプトがクラスターの各システムでブート時に実行されるようにスケジュールし、エフェメラルストレージが常時使用可能であることを確認してください。
- AWS サーバー上に SIOS AMIs がデプロイされていない場合は、これらのディスクの初期化処置を検討する必要があります。これは Windows 2016 から導入され、以降のリリースでも継続されています。
- 管理上の処理 -
- 既存ライセンスのホスト名を変更する
- ライセンスサイト にログイン後、 [License Support] メニューから [List Licenses] を選択します。
- 変更したいライセンスのチェックボックスを選択します。 (1度に 1ライセンスのみ変更可能です)
- [Action] ドロップダウンから [Repair] を選択します。
- 新しいホスト名を入力します。
- [Repair] を選択し、次に [Complete] を選択します。
- ライセンスサイト にログイン後、 [License Support] メニューから [List Licenses] を選択します。
- サーバーに適用されているGPOを確認する方法
問題:
サーバーの再起動後にグループポリシーオブジェクト(GPO)がデプロイまたは再デプロイされることがあり、LifeKeeper(GUI)またはDataKeeperの動作に影響を与える場合があります。
解決策:
以下の2つの方法があります。
[スタート] > [ファイル名を指定して実行] を選択し、 rsop.msc と入力する。- コンソールに、サーバーに適用されているポリシーの一覧が表示されます。
- サーバーに適用されているポリシーの一覧が出力されます。
注意: ユーザーごとに適用されているGPOを確認するには、 gpresult /Scope user /v と入力してください。
- サブスクリプションライセンスの有効期限 -
- サブスクリプションライセンスの有効期限を確認する方法
-
サブスクリプション ライセンスの有効期限を確認するには
1. ライセンスキーインストーラーアプリを開きます
2. [有効期限] 列の下に、サブスクリプションライセンスの有効期限が表示されます。
- LifeKeeper GUI -
- LifeKeeper で OpenJDK をデプロイする
-
注意 v8.7.2以降、OpenJDKはLifeKeeper Coreソフトウェアに含まれるようになりました。
手動で展開する必要がある場合:
- https://openjdk.java.net/ から、Windows x64 インストーラーの OpenJDK をダウンロードします。
- 最初に、ターゲットノードにソフトウェアをデプロイします。
- LifeKeeper で、スイッチオーバー/サービス開始 を実行します。
- スイッチオーバーが完了した後、他のターゲットで上記の手順を繰り返します。
注意: ソースノード/アクティブノードにソフトウェアをインストールすることはないため、これは可用性の高いデプロイメントです。
コマンドプロンプトで以下を実行します
javac -version と入力します。
以下のように出力されます。:
“C:\Windows\system32>javac -version javac 15.0.1”
上記のように出力されない場合は、システム変数 PATH/environment に以下を追加する必要がある場合があります。:
- コントロールパネル\システムとセキュリティ\システム\システムのプロパティ(システムの詳細設定)\
- [詳細設定タブ] を選択します。
- [起動と回復] を選択します。
- [環境変数…] を選択します。
- [Path] を選択し、次に [編集] を選択します。
以下の例のように、文字列に C:\Program Files\Java\jdk-15.0.1\bin を追加します。
C:\Program Files (x86)\Common
Files\Oracle\Java\javapath;SystemRoot%\system32;%SystemRoot;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program
Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\Java\jdk-15.0.1\bin
クラスタ内のすべてのノードで上記の手順を実行します。
- https://openjdk.java.net/ から、Windows x64 インストーラーの OpenJDK をダウンロードします。
- DataKeeper -
- SteelEyeSharedOwnerファイルが削除された場合に再作成する方法
-
共有ディスクを使用する場合、 LifeKeeper は SteelEyeSharedOwner ファイルを使用して共有デバイスの所有権を追跡します。
このファイルがシステムから削除された場合に再生成するには
ボリュームを共有しているすべてのノードで次の手順のいずれかを実行します。
- 両ノードを再起動します。
- ディスク管理を使用して、各ノードでディスクデバイスをオフラインにしてから、オンラインにします。
- ミラー関連 -
- クラスタ化された DataKeeper リソースにミラーを再作成する
問題:
Windows Server フェールオーバークラスター 上で DataKeeper リソースがオフラインとして表示される問題があります。
注意: DataKeeper GUI の既存のジョブは 赤のXマーク がついている状態が多いです。
解決策:
- ソースおよびターゲットノードからすべての古いミラーを削除してください。
- emcmd . createmirror コマンドを使用して手動でミラーを再作成してください。
両ノードからミラー構成を削除する
- cd %extmirrbase%/support と入力してください。 (DataKeeper\Support ディレクトリへのショートカットです。)
- “cleanupmirror (ドライブレター)” を実行してください。 注意: 最初にソース側でこのコマンドを実行してください。 このコマンドは以下を実行します。
- ミラーの構成が削除されます(ボリュームのデータは保持されます)
- スイッチオーバフラグをリセットします。
- ドライバおよびサービスに対してミラーがないことを通知します。
ミラーが正常に削除されたことを確認するため、下記を実行してください。
- cd %extmirrbase% と入力してください。(DataKeeperディレクトリへのショートカットです。)
- run “emcmd . getmirrorvolinfo (ドライブレター)” を実行します。
出力結果からミラーがないことが分かります。 例). 0 サーバー名 0
ここでミラーを手動で再作成します。
構文は下記の通りです。
- emcmd (ソース IP) createmirror (ドライブレター) (ターゲット IP) A または S (同期ミラーの場合は S、非同期ミラーの場合は A)
その後 DataKeeper UI が「再同期」のステータスを表示します。なお、下記のコマンドを実行することで確認することもできます。 - emcmd . getmirrorvolinfo e
出力結果は “E: 1 サーバー名 (ターゲット IP) 2 となり、2 はミラーが「再同期」のステータスであることを示しています。
フェールオーバークラスタリングに戻って、オフラインになっていた DataKeeper リソースをオンラインにしてください。
- ミラーのエンドポイントを削除する
ミラーのエンドポイント削除手順
• ノードのレジストリーにアクセスします。
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ExtMirr\Parameters\Jobs にアクセスします。
• 対象のエンドポイントのジョブを検索して、ジョブからエンドポイントを削除してください。
- ミラーの切替、ミラーの続行とロック、ジョブの削除 (ミラーの削除) アクションがGUIでグレーアウトする
DataKeeperミラーはWindowsフェイルオーバークラスターのDataKeeperボリュームリソースになっているため、 使用不可 のアクションは 太字ではありません。
画面キャプチャに示されているように、 太字ではない または 使用不可 の場合は、エンドユーザーがアクションの上に 「カーソルを合わせる」 と、アクションの説明と代替選択肢が表示されます。
スイッチオーバーミラー – フェイルオーバークラスターマネージャーの「移動」アクションによって実行されます。
続行してミラーをロックする
ジョブの削除(ミラーの削除) – 次のコマンドラインを使用して管理する必要があります。
- cleanupmirror command or if the Job will be required to be deleted also:
- emcmd . deletejob
- ボリュームのロックを解除しないターゲット/パッシブノードのディスクのロックを解除する方法
問題
ターゲット/パッシブノードでボリュームのロックが解除されないという問題が発生しました。
解決策
対象ノードの管理者権限のコマンドプロンプト内で、以下の操作を行ってください。
- “cd %extmirrbase%” (これは DataKeeper ディレクトリへのショートカットです)
- ボリュームのミラーの状態を 確認 します。
(例: EMCMD <system> GETMIRRORVOLINFO <volume letter>)- https://docs.us.sios.com/dkce/8.9.2/en/topic/getmirrorvolinfo (様々なミラーステータスについてはこちらを参照してください。)
- ターゲット ボリュームのミラーリングを 一時停止 します。
(例: EMCMD <system> UNLOCKVOLUME <volume letter>)- https://docs.us.sios.com/dkce/8.9.2/en/topic/unlockvolume
- https://docs.us.sios.com/dkce/8.9.2/en/topic/unlockvolume
上記の操作により、以下のことが可能になりました。
- ディスク管理の起動
- ボリュームの拡張
- DataKeeperのUIに戻る; ミラーを継続しロックする
- 高可用性を維持しながら、既存のクラスターにミラーを作成/追加する方法
-
必要に応じて、「高可用性を維持しながら既存のミラーを削除する方法」をご覧ください。
既存のクラスターにDataKeeperミラーを再度追加するには、以下の手順を実行してください。- ミラーを作成します。
- ミラーを既存のクラスターに登録します。
- 既存のロールに利用可能なストレージを割り当てます。
- 適切な依存関係を追加します。
ミラーの作成
クラスターにミラーを追加するには、 emcmd . createmirror コマンドを使用します。
注意: ミラーを作成する前に、ソース候補(Proposed Source)がフェイルオーバークラスターマネージャー (cluadmin.msc) のオーナーノード(Owner Node)と一致していることを確認してください。
ミラーを作成するための構文:emcmd <Source IP> createmirror <volume letter> <Target IP> <Mirror Type>出力例は、非同期ミラータイプのボリュームSを反映しています。
前述のとおり、ステータスが0の場合はコマンドが正常に完了したことを示し、DataKeeper GUI(datakeeper.msc)にはミラーが再びミラーリング状態として表示されます。
ミラーを既存のクラスターに登録する
コマンドで登録を行うまでは、クラスター内でDataKeeperリソースを使用することはできません。
この例ではボリュームSを登録するためのコマンドは次のとおりです。
完了すると、DataKeeperボリュームが登録され、フェイルオーバークラスターのディスクに表示されます。
既存のロールに利用可能なストレージを割り当てる
DataKeeperボリュームがクラスターに戻ったので、既存の役割(SQL、ファイル共有、Genericアプリケーションなど)に再割り当てする必要があります。
- DataKeeperボリュームを右クリックします。
- [その他のアクション]を選択。
- [別の役割に割り当て…] を右クリックして選択します。
ここでは、SQL Serverロールを例とします。
処理が完了すると、DataKeeperボリュームを含むすべてのリソースが高可用性状態になります。
適切な依存関係を追加する
スイッチオーバーや予期しないフェイルオーバーを正しく動作させるには、DataKeeperに「依存」するリソースに対して適切な依存関係を設定する必要があります。
- SQLの場合、フェイルオーバークラスターマネージャーでSQL Serverを右クリックします。
- Dependenciesのタブを選択します。
- DataKeeperボリュームがリストにない場合は、“Click here to add a dependency”を選択してください。
- 高可用性を維持しながら既存のミラーを削除する方法
DataKeeperの管理タスクの中には、DataKeeperのGUIが提供する機能を超えるものもあるかもしれません。
このような状況に対処するため、DataKeeperミラーリングに参加している各クラスターノードでローカルに実行できる専用コマンドを提供しています。このコマンドは、クラスター化されたリソースと関連データを保持しながら、DataKeeperを「クリーンな状態」にリセットし、継続性を確保し、中断を最小限に抑えます。
タスクは3つあります。
- 管理者はいつ「cleanupmirror」を実行すべきか。
- cleanupmirrorコマンドの実行。
- ミラーが取り外されていることを確認。
管理者はいつ「cleanupmirror」を実行すべきか。
- ミラーリングされた既存のストレージを増設/リサイズしようとした際に、誤った手順を実行した場合
- 既存のミラーリングされたストレージを適切にサイズ変更する方法については、弊社のドキュメント をご覧ください。
- IPアドレス/エンドポイント情報がジョブ情報の出力と一致しない場合
- emcmd . GETJOBINFO を確認してください。
- ミラーが存在しない場合
- DataKeeperボリュームリソースは、フェイルオーバークラスタマネージャー(cluadmin.msc)で引き続き利用可能でオンライン状態です。
- ボリュームがロックされている場合
- 不要なミラーがまだ残っている可能性があります。
- 自動化処理に失敗した場合(PowerShellなど)
CLEANUPMIRRORコマンドを実行する
CLEANUPMIRROR <volume letter>” コマンドは、管理者が既存のミラーを削除できるように、いくつかのタスク(バッチ処理)を実行します。
emcmd . DELETELOCALMIRRORLONLY <volume letter>
emcmd . CLEARSWITCHOVER <volume letter>
emcmd . CLEARBLOCKTARGET <volume letter>
emcmd . SETCONFIGURATION <volume letter> #
emcmd . UPDATEVOLUMEINFO <volume letter>以下はボリュームSが削除対象であるときの出力例です。
ミラーが取り外されたことを確認する
ミラーが削除されたことを確認するには、“emcmd . GETMIRRORVOLINFO S” を実行して、ミラーが存在しないことを確認します。
- 最初の整数は、ソース/ターゲットが存在しないことを示します。
- 最後の整数は、ミラーリング状態ではないことを示します。
注意: このコマンドは、まずソース側でローカルに実行し、その後、残りのすべてのターゲット側で実行する必要があります。DataKeeper GUI/Jobには 赤いX が表示され、ソースとターゲットの情報はDataKeeper GUIに表示されなくなります。
ストレージ、ネットワーク、セキュリティに関する管理作業が完了したら、上記の「高可用性を維持しながら既存のクラスターにミラーを作成/追加する方法」を参照してください。
- エラーメッセージ –
- “emcmd . updatevolumeinfo <drive letter>” 実行後の Status = 87
問題:
LifeKeeper は DataKeeper 経由で作成したミラードライブを使用しています。ドライブを失うとミラーが破損します。そのためミラーの再作成が必要です。
問題のあるノードのエラーを修正するために、次のコマンドを実行します。
- emcmd . deletelocalmirroronly <drive letter>;
- emcmd . clearswitchover <drive letter>;
- emcmd . updatevolumeinfo <drive letter>;
最後のコマンド (updatevolumeinfo) の後、“status=87” エラーメッセージが表示されます。
注目すべき点
Status = 87 の原因は次の通りです。
- ボリュームがロックされている。
- パーティション/ボリュームが存在しない (RAW または不明な状態)。
解決策:
LifeKeeper のミラー/ボリュームの依存関係を削除 します。
前述のコマンド実行とは対照的に、 “cleanupmirror“ を実行すると、同じ手順を実行しますが、より良い結果を得ることができます。
次に、ミラーのソースに対して次の DataKeeper コマンドを実行します。コマンドを実行しない場合、ターゲットミラーは引き続き作成またはロックされます。
- Administrator のコマンドプロンプトを起動します。
- cd %extmirrbase%\support (サポートディレクトリへの短縮)
- “cleanupmirror <drive letter>” を実行します。
次のコマンドを実行して、ミラーが削除されたことを確認します。
- \DataKeeper ディレクトリに移動します。
- emcmd . getmirrorvolinfo <drive letter>; を実行します。
ステータスには 0 <drive letter>; が表示されます。 0 はミラーが存在しないことを示します。
次に、ターゲットノードでこれらの手順を再度繰り返します。
再度次のコマンドを実行して、ミラーがターゲットノードから削除されたことを確認します。- emcmd . getmirrorvolinfo <drive letter>;
ステータスにはl 0 <drive letter>; が表示されます。 0はミラーが存在しないことを示します。
結果:これで emcmd . createmirror コマンドを使用してミラーを再作成できるようになります。LifeKeeper GUI に戻り、 Volume Resource/Mirror をクラスターに追加し直すことができます。
- “emcmd . createmirror” を実行すると、Status = 317 が表示されます。
-
問題
Status = 317 が表示される原因
- emcmd . createmirror コマンドを実行する際、ターゲットボリュームのサイズ (単位:byte) がソースより小さかった。 (DataKeeper ボリュームリソースプライベートプロパティを参照してください。)
- 2×1 の共有構成において emcmd . createmirror を使用してミラーを作成しようとすると Status = 317 が表示される。
解決策2つの方法があります。:
- ターゲットになる場所がミラーリング可能またはミラーリングに適しているかを確認してください。 (以下でボリュームを確認できること。)
- Windows のディスクの管理 (ディスクのプロパティ) – ソース/ターゲットサイズ (単位:byte) が同じもしくはターゲットのほうが大きい。
- ファイルマネージャーまたはディスクの管理のディスクのプロパティ) – ソース/ターゲットサイズ (単位:byte) が同じもしくはターゲットのほうが大きい。
- Windows のディスクの管理 (ディスクのプロパティ) – ソース/ターゲットサイズ (単位:byte) が同じもしくはターゲットのほうが大きい。
- 共有構成に対して
- 問題のあるターゲット側で次のコマンドを実行します。: emcmd . clearblocktarget {ドライブレター}
- 続いて次のコマンドを実行してターゲットが FALSE に設定されていることを確認します。: emcmd . getblocktarget {ドライブレター}
注意: 共有構成のビットマスクは 384 に設定する必要があります。
- “emcmd . getconfiguration {ドライブレター}“を実行することで確認することが可能です。
- 設定されていない場合は 、 “emcmd . setconfiguration 384” を実行し、その後 “emcmd . getconfiguration {ドライブレター}” を実行して設定が反映されていることを確認してください。
追加情報: ミラーの再構築
クラスター/WSFC/フェールオーバークラスターマネージャーで DataKeeper ジョブと DataKeeper ボリュームリソースを維持したままミラーの再構築をする手順は以下の通りです。
- 毎回ソース側から実行してください。
- コマンドプロンプトを管理者権限で 起動します。
- “cd %extmirrbase% “ (DataKeeper Directoryへのショートカット)
- このノード/ソースのミラーの状態を確認します。
- “emcmd . getmirrorvolinfo <ドライブレター>“ と 入力します。 (このコマンドの出力結果については下記リンクを参照してください。)
- “.” を送信先のサーバー、IP、FQDN に変更して状態を確認することが可能です。
- 残っている古いミラーを削除します。
- “cd Support” と 入力します。
- 次のコマンドはローカルミラーのみ削除し (データは保持されます。) 、スイッチオーバーフラグを削除し、SIOS DataKeeper サービスおよびドライバーにミラーが存在しないことを通知します。
- “cleanupmirror <ドライブレター>”
- “cd ..” (DataKeeper ディレクトリーに戻ります。)
- “emcmd . getmirrorvolinfo <ドライブレター>“ この出力として “0 servername 0” が表示されます。
- ターゲット上で前述の手順を繰り返します。
- ここでミラーを手動で再作成します。
- フェールオーバークラスターマネージャーを 起動 してどのサーバーがリソースの現在のオーナーかを決定します。
- これはコマンドプロンプトからミラーを作成する際にソースとなるノードを示します。
- フェールオーバークラスターマネージャーを 起動 してどのサーバーがリソースの現在のオーナーかを決定します。
- ソース側で以下を実行します。
- “emcmd . getjobinfo” を 実行 します
- 出力を使用して ミラーを再作成するための IP アドレス、ドライブレターおよびミラーのタイプ (非同期 (A)/同期(S) ) を確認してください。
ミラーの作成または再作成の構文は以下の通りです。EMCmd <ソース IP> CREATEMIRROR <ボリュームレター> <ターゲット IP> <Type> [オプション]
例
# emcmd 10.x.x.x createmirror D 10.x.x.x A
“Status = 0” が表示されます。- 作成したミラーを確認するため DataKeeper UI に戻ります。
- ターゲットに対して再同期される全てのデータは “再同期中” と表示されます。
全てのミラーの状態が “ミラーリング” になったら、WSFCのロールは 移動/スイッチオーバー の対象となります。考慮すべきコマンド
もっともよく使用されるコマンドは emcmd . get… コマンドです。
ミラーのステータス確認
emcmd . getmirrorvolinfo
emcmd . getserviceinfo
emcmd . getjobinfo
emcmd . getcompletevolumelist
追加情報
- セキュリティとグループポリシーの基準 (アカウント、ポリシー、TCP/IP設定、権限、役割など)
-
- DataKeeper では、NAMED PIPE接続を確立し、DataKeeperのコマンドラインツール (EMCMD) を実行できるように、ネットワークインターフェイスで 「Microsoft ネットワーク用のファイルとプリンタの共有」 が有効になっている必要があります。
NAMED PIPE接続を作成できるかどうかをテストするには、TARGETシステム上でネットワークドライブをマップしてみます。 それが失敗した場合は、NAMED PIPEに問題があります。
- DataKeeperでは、 NetBIOS over TCP/IP および SMB プロトコルが有効になっている必要があります。 GUIが正しく動作しない場合は、次のネットワーク構成が有効になっていることを確認してください。
- 次の例のように、NetBIOS over TCP/IPおよびSMBプロトコルを有効にします。
スタート -> コントロールパネル -> ネットワークとインターネット -> ネットワークと共有センター -> ネットワークアダプタ名 (Ex; Ethernet 2) -> プロパティ -> Internet Protocol Version 4 (TCP/IPv4) -> プロパティ -> 詳細設定 -> WINS -> NetBIOS over TCP/IPを有効にする
- DataKeeper GUIはサーバーのログインIDとパスワードを使用します。 したがって、サーバー自体へのログインに使用するユーザー名とパスワードは各サーバーで同じである必要があり、管理者権限を持っている必要があります。
- ユーザーはドメイン管理者権限でログインする必要があります。
- DataKeeper では、NAMED PIPE接続を確立し、DataKeeperのコマンドラインツール (EMCMD) を実行できるように、ネットワークインターフェイスで 「Microsoft ネットワーク用のファイルとプリンタの共有」 が有効になっている必要があります。





このトピックへフィードバック