前回、VMware Horizon8でFSMOの確認方法を手順にしました。
今回は、Horizon 8でFSMOを別のConnection Serverに転送する手順を検証しました。
期待する目標
本手順で期待する目標は以下の通りです。
- Connection Server でFSMOを転送することができる
- FSMOを持つサーバを理解する
前提条件
構成するサーバについては、前回同様になります。
Connection Server 1号機
- CPU : 2vCPU
- MEM : 4GB
- DISK : 60GB
- Host : dev-vcs01
- FSMO : naming master
Connection Server 2号機
- CPU : 2vCPU
- MEM : 4GB
- DISK : 60GB
- Host : dev-vcs02
- FSMO : schema master
前回から追加されている点としては、各Connection ServerでFSMOのマスターが分かったので、記載しています。
FSMO確認(schema master)
FSMOを転送する前に、GUIでschema masterが確認できるようなので、そこから確認してみます。
[ファイル名を指定して実行]-[ldp]を入力して[OK]を押下します。
ldpが起動したことを確認します。
[ldp]より、[接続]-[接続]を押下します。
[接続]より、以下の設定を行います。
- サーバ : 127.0.0.1 (接続するConnection Server)
- ポート : 389
- コネクションレス : □
- SSL : □
接続するサーバのアドレスについては、自分自身に接続して確認するため、自分自身のループバックアドレスを指定しています。
設定が完了したら、[OK]を押下します。
接続が成功すると、自分自身のLDAP情報が表示されます。
[接続]-[バインド]を押下します。
[バインド]より、以下の設定を行います。
- バインドの種類 : 現在のログオンユーザとしてバインド
- バインド後のトラフィックを暗号化する : ■
設定が完了したら、[OK]を押下します。
バインドが成功すると、認証情報が表示されます。
バインドが成功したら、[表示]-[ツリー]を押下します。
[ツリー表示]より、[ベース]のドロップダウンリストを表示し、[CN=Schema,CN=Configuration,~]を選択します。
[ツリー表示]-[ベース]にschemaのCNが設定されていることを確認し、[OK]を押下します。
スキーマが表示されていることを確認します。
スキーマツリーより、[fSMORoleOwner]を確認し、オーナーのCNが[dev-vcs02(クラスタ内に存在するホスト名)]となっていることを確認します。
これで、Connection Server 2号機がschema masterを持っていることが確認できました。
FSMO 転送(schema master)
FSMOの所有ノードが確認できたら、スキーママスターを別のConnection Serverに転送してみます。
なお、今回はConnection Serverの2号機がFSMOを持っていたので、転送のコマンドはConnection Server1号機から実行します。
FMSOが乗っているホストで実行しても自分自身に再転送することになります。
例によって例のごとく、FSMOの確認コマンドを実行していきたいと思います。
コマンドで確認できるのであれば、LDPは必要なかったのではないか？という意見がありそうですが、ごもっともです。
以下のコマンドを実行し、FSMOのschema masterを転送します。
注意点としては、コマンドを実行する場所は、fsmo maintenanceとなるため、必要に応じてfsmo maintenanceまでコマンドを移動させておく必要があります。
> dsmgmt
dsmgmt: roles
fsmo maintenance: connections
server connections: connect to server <接続するサーバのFQDN>:389
<接続するサーバのFQDN>:389に接続しています...
ローカルでログオンしているユーザの資格情報を使って<接続するサーバのFQDN>:389に接続しました。
server connections: quit
fsmo maintenance: #接続し、fsmo maintenanceの場所でFSMO転送コマンドを実行します。
fsmo maintenance : seize schema master色々とコマンドを実行していますが、dsmgmtで自分自身のサーバに接続後、fsmo maintenanceで転送コマンドを実行します。
[役割の強制確認ダイアログ]が表示され、役割を次のサーバに転送するか確認が入るため、転送先のConnection Serverを確認し、[OK]を押下します。
転送が完了すると、[FSMO転送は終了しました。-強制処理(seize)は必要ありません。]を表示され、その下に、スキーマがdev-vcs01となっていることを確認します。
転送後に、LDPより、fSMORoleOwnerが転送されていることを確認します。
LDPの表示については、ツリー表示を再度実行すると更新された情報が再度表示されます。
念のため、Connection Server2号機でもSelect operation targetを確認して、1号機と同様の結果になっていることを確認します。
以上でFSMO転送(schema master)は完了です。
FSMO 転送(naming master)
次に、名前付けマスタの転送を行っていきます。
先ほどスキーマを1号機に移したので、今回はスキーマと名前付けマスタをConnection Server2号機に転送してみたいと思います。
Connection Server 1号機→Connection Server 2号機へ転送するため、操作を行うConnection Serverは2号機になります。(この場合、Connection Server 1号機から2号機に接続して転送してもよい)
Connection Server 2号機のfsmo maintenanceより、[seize schema master]を実行し、スキーママスタを2号機へ転送します。
スキーママスタが2号機に転送されたことを確認します。
名前付けマスタを転送するには、fsmo maintenanceより、以下のコマンドを実行します。
fsmo maintenance: seize naming masterコマンドを実行すると、[役割の強制確認ダイアログ]が表示されるため、転送先のConneciton Serverを確認し、[OK]を押下します。
転送が完了したら、[list roles for connected server]コマンドでマスタを所有しているサーバを確認します。
今回のコマンドで、スキーママスタと名前付けマスタの両方がConnection Server 2号機に移動しました。
以上でFSMO転送(naming master)は完了です。
まとめ
前回はFSMOがどのConnection Serverに存在するかの確認を行いました。
今回は、実際にFSMOを転送する手順を検証してみました。
FSMOの転送自体はWindowsのActive Directoryと同様に実行することができました。
このコマンドを知っているとFSMOが乗っているConnection Serverを意識して作業ができるので、障害発生時の切り分けや構成変更する際に考慮することができ、意図しない障害を避けることができると思います。
Active Directoryでもそうですが、FSMOのマスタさえ生きていればどうにでもなる感はあるので、FSMOの確認と移動ができれば最悪の事態は避けることができる気がしています。
おまけ
本ブログではVMwareやWindows、Linuxのインストール手順等も公開しております。
インフラエンジニアとして有益な記事や無益なコンテンツも作成しておりますので、通勤時間や休憩時間、休日のスキマ時間等に合わせて読んでいただけると幸いです。
また、Youtubeで解説動画も鋭意作成中です。本ブログで記事にしているものも動画にしようと思っておりますので、よろしくお願いいたします。
willserverのnoteも開設したのでフォローお願いします。
コメント