Windows2003R2からWindows2012R2へドメインを移行してきました。
「WS2012R2ドメインコントローラーがらみの不具合（KB2989971）」
については対処済。
ついでにWSUSを同居させるということで役割を追加…できない。
そういえばWIDの権限周りでエラー出るんだったかな。
面倒くさいので「ALL SERVICE」を追加
グループポリシーの管理を開く
ドメインコントローラーなので
「Defalt DomainControler Policy」を開く
コンピューターの構成
→Windowsの設定
→セキュリティの設定
→ローカルポリシー
→ユーザー権利の割当
→サービスとしてログオン
「ユーザーまたはグループの追加」で「NT SERVICE\ALL SERVICES」と入力
※参照ボタンなんかは無いので手打ちで追加
対象のサーバーで「gpupdate /force」を実行。
無事WSUSのインストール完了。
ちなみにWSUSインストール後にADの役割追加した場合はエラーなし。
しかし、そのうちWSUSマネージャーが表示されなくなる。
原因は同じなのでこの手順を行えば復旧する。
2015年12月28日月曜日
2015年12月22日火曜日
NetAppコマンドメモ（7-mode/基本操作）
7-modeがFAS2500シリーズ販売終了のタイミングで新規導入が不可能になるみたいですね。
正直CDOTが別物すぎてリプレイス考えると頭が痛いです。
販売終了したとしてもしばらくは動き続けると思うので
忘れてしまわないようにコマンドメモ
【シャットダウン】
NetApp > halt
※クラスタ構成の場合は「halt -f」でフェールオーバーせずに停止
【LORDERプロンプトからの起動】
LORDER > bye
LORDER > boot_ontap
どちらでも良いと思うが基本byeを使ってる気がする。
byeの場合はシステムをリセットして起動する。
Ontapのバージョンアップなんかを行った場合はシステムリセットが必要なのでbyeを実行する必要あり。
【システム構成情報の確認】
NetApp > sysconfig [-A|-c|-d|-h|-m|-r|-t|-V]
-A 全ての項目を表示
-c 各PCIスロットの構成をチェック
-d ディスクに関する情報を表示
-m テープ装置のjukeboxに関する情報を表示
-t テープ装置のDriveに関する情報を表示
-r RAIDに関する情報を表示
-V ボリュームに関する情報を表示
【容量の確認】
Aggregateの容量確認
NetApp > df -hA [aggregate名]
※[aggregate名]省略時は全てのAggregate情報表示
ボリュームの容量確認
NetApp > df -h [volume名]
※[volume名]省略時は全てのボリューム情報を表示
ボリュームのinode数確認
NetApp > df -i [volume名]
※[volume名]省略時は全てのボリューム情報を表示
inodeについて
ボリュームに登録できるファイル数
ボリュームサイズに比例して初期値が上昇するが、3000万程で頭打ちになる
（数TBくらいのボリュームで下限値が頭打ちになるみたい）
1ボリュームに格納するファイル数が多くなるシステムについては拡張が必要
【inode数の拡張】
NetApp > maxfiles [volume名] [inode数]
【inode数の上限を確認】
NetApp > maxfiles [volume名] -1
ありえない数値を入力する事で設定できるinode範囲を確認する事ができます。
【初期設定】
NetApp > setup
※setup後再起動することで設定が反映
IPやホスト名等をウィザード形式で設定
■Aggregate/Volume
【Aggregate作成】
NetApp > aggr create [aggregate名] ディスク本数
ディスクを指定して組みたい場合は
NetApp > aggr create [aggregate名] -d ディスクID
ディスクIDの確認は「sysconfig -d」
【Aggregateへのディスク追加】
NetApp > aggr add [aggregate名] ディスク本数
ディスクを指定して追加する場合は
NetApp > aggr add [aggregate名] -d ディスクID
【Aggregate削除】
Aggregateをオフラインに変更
NetApp > aggr offline [aggregate名]
Aggregateを削除
NetApp > aggr destroy [aggregate名]
Aggregateを構成していたディスクはスペアディスクとなるが、
ディスクを初期化するまで使用できない。
【ディスクの初期化】
NetApp > disk zero spares
ディスク容量が大きい程時間がかかるので夕方に実行して放置が無難
【Aggregateの情報確認】
Aggregateの状態を表示
NetApp > aggr status
Aggregateを構成するディスク情報の表示
NetApp > sysconfig -r
【ボリュームの作成】
NetApp > vol create [volume名] [aggregate名] ボリュームサイズ
【ボリュームのサイズ変更】
NetApp > vol size [volume名] [+/-][size][k/m/g/t]
例1：ボリュームを200G増やす
NetApp > vol size pikkoro +200g
例2：ボリュームを200Gにする
NetApp > vol size pikkoro 200g
【SnapShot領域の変更】
NetApp > snap reserve [volume名] [0 - 100]
デフォルトでは5%（Ontap7xの場合は20%）
【ボリュームの削除】
ボリュームをオフラインにする
NetApp > vol offline [volume名]
ボリュームを削除する
NetApp > vol destroy [volume名]
【ボリュームの状態表示】
ボリュームの状態表示
NetApp > vol status [volume名]
正直CDOTが別物すぎてリプレイス考えると頭が痛いです。
販売終了したとしてもしばらくは動き続けると思うので
忘れてしまわないようにコマンドメモ
【シャットダウン】
NetApp > halt
※クラスタ構成の場合は「halt -f」でフェールオーバーせずに停止
【LORDERプロンプトからの起動】
LORDER > bye
LORDER > boot_ontap
どちらでも良いと思うが基本byeを使ってる気がする。
byeの場合はシステムをリセットして起動する。
Ontapのバージョンアップなんかを行った場合はシステムリセットが必要なのでbyeを実行する必要あり。
【システム構成情報の確認】
NetApp > sysconfig [-A|-c|-d|-h|-m|-r|-t|-V]
-A 全ての項目を表示
-c 各PCIスロットの構成をチェック
-d ディスクに関する情報を表示
-m テープ装置のjukeboxに関する情報を表示
-t テープ装置のDriveに関する情報を表示
-r RAIDに関する情報を表示
-V ボリュームに関する情報を表示
【容量の確認】
Aggregateの容量確認
NetApp > df -hA [aggregate名]
※[aggregate名]省略時は全てのAggregate情報表示
ボリュームの容量確認
NetApp > df -h [volume名]
※[volume名]省略時は全てのボリューム情報を表示
ボリュームのinode数確認
NetApp > df -i [volume名]
※[volume名]省略時は全てのボリューム情報を表示
inodeについて
ボリュームに登録できるファイル数
ボリュームサイズに比例して初期値が上昇するが、3000万程で頭打ちになる
（数TBくらいのボリュームで下限値が頭打ちになるみたい）
1ボリュームに格納するファイル数が多くなるシステムについては拡張が必要
【inode数の拡張】
NetApp > maxfiles [volume名] [inode数]
【inode数の上限を確認】
NetApp > maxfiles [volume名] -1
ありえない数値を入力する事で設定できるinode範囲を確認する事ができます。
【初期設定】
NetApp > setup
※setup後再起動することで設定が反映
IPやホスト名等をウィザード形式で設定
■Aggregate/Volume
【Aggregate作成】
NetApp > aggr create [aggregate名] ディスク本数
ディスクを指定して組みたい場合は
NetApp > aggr create [aggregate名] -d ディスクID
ディスクIDの確認は「sysconfig -d」
【Aggregateへのディスク追加】
NetApp > aggr add [aggregate名] ディスク本数
ディスクを指定して追加する場合は
NetApp > aggr add [aggregate名] -d ディスクID
【Aggregate削除】
Aggregateをオフラインに変更
NetApp > aggr offline [aggregate名]
Aggregateを削除
NetApp > aggr destroy [aggregate名]
Aggregateを構成していたディスクはスペアディスクとなるが、
ディスクを初期化するまで使用できない。
【ディスクの初期化】
NetApp > disk zero spares
ディスク容量が大きい程時間がかかるので夕方に実行して放置が無難
【Aggregateの情報確認】
Aggregateの状態を表示
NetApp > aggr status
Aggregateを構成するディスク情報の表示
NetApp > sysconfig -r
【ボリュームの作成】
NetApp > vol create [volume名] [aggregate名] ボリュームサイズ
【ボリュームのサイズ変更】
NetApp > vol size [volume名] [+/-][size][k/m/g/t]
例1：ボリュームを200G増やす
NetApp > vol size pikkoro +200g
例2：ボリュームを200Gにする
NetApp > vol size pikkoro 200g
【SnapShot領域の変更】
NetApp > snap reserve [volume名] [0 - 100]
デフォルトでは5%（Ontap7xの場合は20%）
【ボリュームの削除】
ボリュームをオフラインにする
NetApp > vol offline [volume名]
ボリュームを削除する
NetApp > vol destroy [volume名]
【ボリュームの状態表示】
ボリュームの状態表示
NetApp > vol status [volume名]
2015年12月21日月曜日
[NetApp＋VMware]NetApp内NFSボリュームから仮想マシンを削除する際の注意点
NetApp（NFS）＋VMware環境での話。
同一ボリューム内に複数の仮想マシンを作成した場合、
仮想マシンの削除には注意が必要です。
具体的には
「削除するVMの容量分、ボリュームに空き容量を持っておく必要がある」
という事に注意ください。
※NetApp上でSnapshotを取得していないボリュームであれば対象外ですが少数かと思います。
例えばNetApp上に300GBのボリュームがあるとします。
※Snapshotを取得した状態のボリュームとします。
NetAppのステータスを確認してみます。
NetApp > df -h
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 200GB 100GB 66% /vol/pikkoro/
/vol/pikkoro/.snapshot 10GB 1GB 99GB 10% /vol/pikkoro/.snapshot
このボリュームはESXiにマウントされおり、usedの200GBは以下のVMにより消費されています。
「pikkoro1-VM」(100GB)
「pikkoro2-VM」(100GB)
この状態で「pikkoro1-VM」を削除してみます。
しばらく時間を置いてNetAppのステータスを確認してみます。
NetApp > df -h
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 200GB 100GB 66% /vol/pikkoro/
/vol/pikkoro/.snapshot 10GB 101GB 0GB 1001% /vol/pikkoro/.snapshot
削除したVMの容量分スナップショット領域に増えています。（←わかる）
しかし、usedが減っていません。（←？？？）
snapshot領域から溢れている容量は実領域を侵食してしまいます。
しかもステータス上は確認できません。
先ほどの「df -h」で見える「/vol/pikkoro/」のステータス、実際は以下のようになっています。
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 291GB 9GB 97% /vol/pikkoro/
.snapshot領域から溢れた91GBが消費されているので、実際は残り9GBしか無い事になります。
気がついたらVMが止まっているといった状況が想定されます。
対処法ですが、事前にSnapshot（SnapMirror用のSnapshotも含む）を全て削除すれば回避することができます。
…が、バックアップで利用しているケースがほとんどかと思いますのでバックアップを飛ばす事になります。
SnapMirrorを構成している場合は初期転送が必要となってしまいさらに現実的ではありません。
※VM削除後にSnapMirrorのUpdateを実行すれば初期転送は必要ありません。
なので最初に申し上げた通り
「削除するVMの容量分、ボリュームに空き容量を持っておく必要がある」
という結論に至りました。
これ、結構痛い目見た人もいるんじゃないでしょうか。。。
同一ボリューム内に複数の仮想マシンを作成した場合、
仮想マシンの削除には注意が必要です。
具体的には
「削除するVMの容量分、ボリュームに空き容量を持っておく必要がある」
という事に注意ください。
※NetApp上でSnapshotを取得していないボリュームであれば対象外ですが少数かと思います。
例えばNetApp上に300GBのボリュームがあるとします。
※Snapshotを取得した状態のボリュームとします。
NetAppのステータスを確認してみます。
NetApp > df -h
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 200GB 100GB 66% /vol/pikkoro/
/vol/pikkoro/.snapshot 10GB 1GB 99GB 10% /vol/pikkoro/.snapshot
このボリュームはESXiにマウントされおり、usedの200GBは以下のVMにより消費されています。
「pikkoro1-VM」(100GB)
「pikkoro2-VM」(100GB)
この状態で「pikkoro1-VM」を削除してみます。
しばらく時間を置いてNetAppのステータスを確認してみます。
NetApp > df -h
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 200GB 100GB 66% /vol/pikkoro/
/vol/pikkoro/.snapshot 10GB 101GB 0GB 1001% /vol/pikkoro/.snapshot
削除したVMの容量分スナップショット領域に増えています。（←わかる）
しかし、usedが減っていません。（←？？？）
snapshot領域から溢れている容量は実領域を侵食してしまいます。
しかもステータス上は確認できません。
先ほどの「df -h」で見える「/vol/pikkoro/」のステータス、実際は以下のようになっています。
Filesystem total used avail capacity Mounted on
/vol/pikkoro/ 300GB 291GB 9GB 97% /vol/pikkoro/
.snapshot領域から溢れた91GBが消費されているので、実際は残り9GBしか無い事になります。
気がついたらVMが止まっているといった状況が想定されます。
対処法ですが、事前にSnapshot（SnapMirror用のSnapshotも含む）を全て削除すれば回避することができます。
…が、バックアップで利用しているケースがほとんどかと思いますのでバックアップを飛ばす事になります。
SnapMirrorを構成している場合は初期転送が必要となってしまいさらに現実的ではありません。
※VM削除後にSnapMirrorのUpdateを実行すれば初期転送は必要ありません。
なので最初に申し上げた通り
「削除するVMの容量分、ボリュームに空き容量を持っておく必要がある」
という結論に至りました。
これ、結構痛い目見た人もいるんじゃないでしょうか。。。
登録:
投稿 (Atom)