仕事 Archive

グローバルで設定。

#DHCP

#dhcp relay server-group 0 ip 192.168.1.1

vlan interfaceで設定

#dhcp select relay

#dhcp relay server-select 0

斜体の0は0から9までの間で自由に設定する。

仮想マシン上に業務システムを構築する案件。納入先が遠距離ということもあって、V2V2Vを駆使して環境を構築することになりました。

1. ESX3.5が稼働している環境で仮想マシンを作成
2. vCenter ConverterのBootCDで仮想マシンをブートさせ、VMware Server向けの.vmdkにコンバート
3. 社内に持ち帰ってVMware Serverにインポートして色々設定
4. 再びvCenter ConverterのBootCDでコンバート
5. Converter Standaloneで、仮想マシンをESX3.5にインポート

ざっくりとした手順はこんな感じです。

vmfsデータストアから直接FTPやSCPでダウンロードする方法がありますが、ESXのバージョン違いなどでトラブルがありそうなので、Converterを利用することにしました。

コンバートしたvmdkはUSB-HDDで運びましたが、帯域さえあればネットワーク越しで運べるので、改めて仮想化のメリットを感じることが出来た仕事です。

ある理由からXenApp (Presentation Server)の勉強をしています。

サーバのインストールとアプリケーションの公開方法までは簡単ですが、どう設定していくのか、という部分でコツが要るんだろうな…という印象です。

以前からちょっとずつ作ってはいましたが、テンプレートとして作成中。

退職した先輩が残したものを細々修正するか、一から作るか。

結局一から作り直してます。

最終的に紙に出力するから様式が大事で、Wordになりそうです。

年度末の仕事になりそう。

ATM回線からPPPoEへの切り替え。

今使っているルータがPPPoEに対応してるのかどうか不明なので、そこから調べていかないと。

設計は今のものを踏襲するつもりで、あまり悩んではいないです。

問題は開通までのリードタイムだなあ。

CactiEZの導入後はcactiの設定です。

 

＜ポーリング間隔の修正＞

デフォルトだと1分間隔です。

監視対象への負荷が気になるので5分間隔に変更しました。

 

＜機器登録の流れ＞

1.監視対象の機器を登録する

<Management>-<Devices>から登録します。

 

2.登録した機器のグラフを作成する

<Devices>での登録後、そのまま<Create Graph for this host>でグラフを作成します。

 

3.作成したグラフをグラフツリーに登録する

<Devices>で一覧表示されている機器をクリックし選択後、右下のメニューから登録したいグラフツリーを選び、Moveします。

 

＜Monitorの設定＞

機器の登録時にMonitorの対象にするかどうか選択できます。

登録しておくとMonitorタブでアイコンが表示されます。機器の死活状態や、グラフへのリンクが用意されるので大変便利です。

アイコンの並び方を選べるので、グラフのTreeで分けるようにしました。

が、うまく並びません。

Treeのトップレベルで分けようとするとグループ分けがうまくいきません。

結論から言うとトップレベルの下にHeaderを作り、そこでグループ分けするようにするとうまくいきました。

 

 

ここまでで対象機器のトラフィック監視（グラフ化）と死活監視ができます。

CentOS5にcactiをインストールしていましたが、OSがぶっ飛んでしまったので久しぶりにcactiで検索するとCactiEZなるプロダクトがリリースされていました。

CentOSをベースにCactiの主要プラグインをまとめたパッケージです。cactiは環境依存が結構あるので、これは便利。

早速新しくVMを作成してインストールしました。手順をまとめます。

＜準備するもの＞

・CactiEZのISOファイル （リンク先はISOをtar.gzしてあるもの）

 

＜インストールの手順＞

１．VMはメモリが512MB、HDDは8GBで作成。

２．CactiEZのISOをCD-ROMドライブにConnectしてインストールCDからブート。

３．boot:プロンプトでEnterを押すとインストールが開始。

４．15分程度でインストール完了。

 

＜環境設定＞

やらないといけないことは、オフィシャルサイトに記載があります。一応順番に進めます。

1.ネットワーク設定 

表示される画面に沿って自分のネットワーク環境に応じて設定します。設定後、ネットワーク関係のデーモンを再起動します。

# netconfig
# service network restart

2.時刻合わせ

真っ先にこのコマンドで時刻合わせをします。

# ntpdate -u ntp.nict.jp

言うまでもないですが、監視システムの時刻合わせはかなり重要です。

3.Changing the root password

誰も見なくても変更しておきましょう。

# passwd

4.FTPサーバは無効

データのやりとりにはWinSCPかPuttyを使ってください。

5.自動更新(yum)の無効化

デフォルトでyumが有効なので無効にします。

もちろんアップデートをかけ続けたいときはそのままでOKです。私は依存関係が崩れるのが嫌なので無効にしました。

# service yum stop
# chkconfig yum off

6.キーボード配列の変更

私は不要ですが、必要な方もおられるかもしれません。

# yum install system-config-keyboard
# system-config-keyboard

7.タイムゾーンの変更

監視システムにとっては時刻同期は肝です。色々な方法がありますが、次の手順で変更しました。

# cp -a /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

8.GUI環境のインストール

個人的には不要ですが、必要なら次のコマンドでインストールしてください。

# yum groupinstall "X Window System" "KDE (K Desktop Environment)"

9.cronでntpdateを実行させる

VMとCentOSの相性と言われますが、時刻ズレが生じます。先述した通り、時刻がズレているのは致命的なのでcronでntpdateを実行させることで無理矢理合わせてます。

rootのcrontabを編集します。

# crontab –e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/sbin/ntpdate –s ntp.nict.jp

10.完了

一応ここまでで環境の設定は終わりです。

あとはcactiの設定になります。

Web経由でのウィルス対策としてFortigateを提案しようと評価していましたが、色々制限がありそうなので躊躇しています。

制限というのは監視対象のポートがTCPの80番ポートのみ、ということです。

ネットワークの最上位にFortigateがあるなら何も問題は起こりません。環境によっては、部門境界にFortigateがあり、それを挟んでProxyがあったりします。

そんな環境で下位Proxyと上位Proxyの接続ポートが80以外だと、FortigateのHTTPスキャンが使えないことになります。

UPSを置き、正しく設定すれば放っておいてもいいはずなんですが、停電となるとサーバ類を停止させます。

停電対応の時、一番怖いのが復帰しない機器が出てくることです。

今回はそういった機器が出なかったので良かったです。やはりサーバルームに設置するようになってから故障率がぐっと下がっています。

大抵の場合はメンテナンス時間を多めに見積もっているので、余った時間でOSにパッチを当てたり、アプリのバージョンアップを行ったりしています。

今回は大きな問題も無く作業が済んでほっとしました。

ESXがあり得ない壊れ方をしたので、vRangerで復旧することになりそうと思って下書きを書いていましたが、不要となってしまいました。

復旧に備えて、念のためサポートに確認したところ次のような回答をいただいたので、メモしておきます。

有償サポート窓口からの回答なので、差し障りの無い範囲にとどめておきます。

ドメイン・コントローラであっても、vRangerのリストア方法としては変わらない。

ただ、仕様上完全な静止点を作れないため、ActiveDirectoryの整合性が保たれない可能性がある。

NTBackupなどでドメイン・コントローラの情報をバックアップし、必要であればそちらを書き戻すように。

SymantecのBackup Exec System RecoveryやAcronis True Imageなどと同様の様子です。

ドメイン・コントローラの復旧では非Authoritative（他のDCが最新）やAuthoritative（自分が最新）などの要注意ポイントあります。昔は相当ビビってましたが、随分慣れたものです。