格安スイッチのCiscoSmallBusinessですが大きな落とし穴がありますのでご注意ください。
このスイッチ、ARPテーブルを100程度しか持てません。
100～を超えるエントリは記憶できませんのでパケットを受け取る度にARP解決を行う模様です。
%ARP-E-ARPTBL: ARP Table Overflow, aggregated
↑
こんなエラーを吐きます。
200台程端末のある環境に入れると、ネットワークが超遅くなるわけです。
一応ある程度は拡張可能とのこと。
【変更方法】
1.各種管理 ＞TCAM割り当て設定
2.デフォルトは「128」 → 「256」等に変更（上限「456」）
3.適用
※適用を押すと問答無用で再起動がかかりますので注意！
TCAMの登録は456までで、ARPテーブル以外にもQoSやACL等でも消費されるという事で
最大まで設定することはお勧めできないとか。
これでもOverFlowエラーが出る場合は、以下の処置をとの事
・配下の機器を100台以下にする
・SG300を増やして負荷分散する
・Catalystに替える
…名前の通り端末数100台以下のスモールオフィスに導入しましょう。
仕様にMACテーブル最大16,384個とか、VLAN4096個同時サポートとか書いてあるけど使えねぇじゃないですか…
以前は地味にACLが物理IFにしか当てれなかったのですが、バージョンアップによりVLANにも当てれるようになったみたいですね。
2017年1月31日火曜日
AVAYA民事再生法申請・・・
米国アバイア社が米国にてCahpter11（民事再生法）の申請を行った模様です。
日本アバイアは現時点で販売継続の方針との事。
Nortelで駄目だったのだから長くはないかもと思っていましたが…
Radware社は大丈夫だろうか。Alteonは結構動いてるんだよなぁ。
ERS3500でACLが2行しか書けなかったのは苦い思い出…
日本アバイアは現時点で販売継続の方針との事。
Nortelで駄目だったのだから長くはないかもと思っていましたが…
Radware社は大丈夫だろうか。Alteonは結構動いてるんだよなぁ。
ERS3500でACLが2行しか書けなかったのは苦い思い出…
2015年12月28日月曜日
AD環境にWSUSを追加（Windows2012R2）
Windows2003R2からWindows2012R2へドメインを移行してきました。
「WS2012R2ドメインコントローラーがらみの不具合（KB2989971）」
については対処済。
ついでにWSUSを同居させるということで役割を追加…できない。
そういえばWIDの権限周りでエラー出るんだったかな。
面倒くさいので「ALL SERVICE」を追加
グループポリシーの管理を開く
ドメインコントローラーなので
「Defalt DomainControler Policy」を開く
コンピューターの構成
→Windowsの設定
→セキュリティの設定
→ローカルポリシー
→ユーザー権利の割当
→サービスとしてログオン
「ユーザーまたはグループの追加」で「NT SERVICE\ALL SERVICES」と入力
※参照ボタンなんかは無いので手打ちで追加
対象のサーバーで「gpupdate /force」を実行。
無事WSUSのインストール完了。
ちなみにWSUSインストール後にADの役割追加した場合はエラーなし。
しかし、そのうちWSUSマネージャーが表示されなくなる。
原因は同じなのでこの手順を行えば復旧する。
「WS2012R2ドメインコントローラーがらみの不具合（KB2989971）」
については対処済。
ついでにWSUSを同居させるということで役割を追加…できない。
そういえばWIDの権限周りでエラー出るんだったかな。
面倒くさいので「ALL SERVICE」を追加
グループポリシーの管理を開く
ドメインコントローラーなので
「Defalt DomainControler Policy」を開く
コンピューターの構成
→Windowsの設定
→セキュリティの設定
→ローカルポリシー
→ユーザー権利の割当
→サービスとしてログオン
「ユーザーまたはグループの追加」で「NT SERVICE\ALL SERVICES」と入力
※参照ボタンなんかは無いので手打ちで追加
対象のサーバーで「gpupdate /force」を実行。
無事WSUSのインストール完了。
ちなみにWSUSインストール後にADの役割追加した場合はエラーなし。
しかし、そのうちWSUSマネージャーが表示されなくなる。
原因は同じなのでこの手順を行えば復旧する。
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)