SyntaxHighlighter

2015年10月31日土曜日

HinemosにMIB取り込み

オープンソースソフトウェアのHinemosは有料オプション買わないとMIBの取り込みができません。 デフォルトで多数のMIBを持っているのですが、それに無いTrapを受けると全部重要度が「不明」になって正直使い物にならないので、SNMP Trap監視をHinemosでやろうとする場合は要注意です。

2015年10月12日月曜日

雅購入&みおふぉんSIMサイズ変更

Freetel 雅 購入しましたー。3万弱クラスのスペックを持ちながら2万で買えて、日本メーカーだから某国産のように勝手にデータがどこかに送られているんではという心配もないし、5インチというお手ごろサイズだし、電池パック交換可だから長く使えそうだし、ハイスペック求めてないユーザーにはとても有り難い機種ですね。ハイスペックじゃないと言っても、これまで使っていたSO-03Dに比べるとちょっとハイスペック。サクサク動きます。嫁さんはホワイト、私はブラックなんですが、ブラックめちゃくちゃ指紋つきます、というか目立ちます。

SIMはみおふぉん使ってます。SO-03Dは標準SIMでしたが雅はマイクロSIMなので、サイズ変更を申し込みました。ちょうどキャンペーン中で変更手数料無料。ラッキー。変更にかかった期間をメモしておきます。

  • 木曜の夜にWEBから申し込み。
  • 土曜の昼過ぎに旧SIMが使えなくなる。
  • 日曜の朝6:30にIIJから到着予定日のメール(ちなみに到着予定日は当日でした)。
  • 日曜の午前中に新SIM到着(ヤマト)。

てっきり平日日中のみの対応だろうと思ったら、24時間365日体制なんですね・・・。すごい。

2015年10月11日日曜日

VSC 5.0 / 6.0 での Single File Restore 手順

VSC は 5.0 から Single File Restore 機能が無くなってしまいました。噂では 6.2 で復活するらしいですが、まだ少し先の話です。で、今回は手動で Single File Restore を行ってみたのでその手順を説明します。責任は取れませんので参考までに。検証に使用した環境は clustered Data ONTAP 8.3P1、VSC6.0、vSphere6.0 です。
尚、対象は Windows のみです。Linux の場合の手順は非常に複雑かつ環境依存が激しいので汎用的な手順を作るのは難しそうです。どうしても Linux で Single File Restore しなければならない状況になってしまった場合は英語ですが参考になりそうなリンクを貼っておきますので見てみてください。

では Windows での Single File Restore 手順です。尚、リストア対象の仮想マシンは電源ONの状態で作業を開始し、完全に作業が完了するまでは再起動をしないでください。

  1. vSphere Web Client でリストア対象の仮想マシンを右クリックして、[NetApp VSC]->[Backup]->[Mount Backup]をクリックします。
  2. リストアしたいバックアップを選択して、対象の仮想マシンが所属している ESXi ホストを選択し、[OK]をクリックします。
  3. [OK]をクリックします。
  4. 対象の仮想マシンを右クリックして、[Edit Settings...]をクリックします。
  5. [New device]で[Existing Hard Disk]を選択して[Add]をクリックします。
  6. マウントされたバックアップデータストアから対象の仮想マシンを選択し、[Contents]で VMDK ファイルを選択して[OK]をクリックします。画像では見切れていますが、2番目と3番目のファイルは -00000x.vmdk すなわち VMware snapshot ファイルです。無視して『仮想マシン名.vmdk』を選択してください。
  7. [OK]をクリックします。
  8. 仮想マシンの再構成が始まって数秒すると、画面に警告メッセージが表示されます。[Answer Question...]をクリックします。
  9. UUID が重複しているという警告です。[Yes]を選択して[OK]をクリックします。
  10. [Recent Tasks]で仮想マシンの再構成が完了したことを確認します。
  11. 対象の仮想マシンにログインし、ディスクの管理画面を開きます。以下の画像は2012の場合で、[サーバーマネージャー]->[ツール]->[コンピューターの管理]をクリックします。
  12. 追加されたディスクを右クリックして、[オンライン]をクリックします。
  13. 2012では自動的にドライブレターが割り当てられました。OSバージョンや設定(自動マウントを無効にしている)によっては手動でドライブレターを割り当ててください。
  14. エクスプローラに追加ディスクが表示されました。目的のファイルをコピーしてリストアします。
  15. リストアが完了したら、ディスクの管理画面で追加ディスクを右クリックして[オフライン]をクリックします。
  16. オフライン表示になったことを確認します。
  17. vSphere Web Client で対象の仮想マシンを右クリックして、[Edit Settings...]をクリックします。
  18. 追加したハードディスクの[×]をクリックします。
  19. [OK]をクリックします。
  20. [Recent Tasks]で仮想マシンの再構成が完了したことを確認します。
  21. 対象の仮想マシンからディスクが見えなくなったことを確認します。
  22. vSphere Web Client で対象の仮想マシンを右クリックし、[NetApp VSC]->[Backup]->[Unmount Backup]をクリックします。
  23. アンマウント対象のバックアップを選択して[OK]をクリックします。
  24. [OK]をクリックします。
  25. マウントしたバックアップデータストアが見えなくなっていることを確認します。以上で完了です。

ちなみに、電源OFFで始めてしまった場合や、途中で再起動した場合など、バックアップディスクを仮想マシンにくっつけた状態でOS起動してしまうと、色々と不具合が出ます。その場合は一度追加したディスクを取り外してやり直してください。もしくは、リストア対象の仮想マシンとは別の仮想マシンにバックアップディスクをくっつけて、ファイル共有でリストアするのもありだと思います(サイズによっては帯域と時間とを消費しますが)。

2015年10月10日土曜日

VSC 4.2.X での Single File Restore 手順

NetApp の Virtual Storage Console (VSC) 4.2.X は Single File Restore という、ファイルレベルでのリストア手段を持っています(ただし Windows のみ。Linux はダメ)。
リストアは管理者が実行するモードとユーザ自身に実行させるモードがあるのですが、よほど頻度が高くない限りは管理者が実行したほうが安パイかなと思います(少なくともバックアップディスクがOSから見えるようになるところまでは)。よって管理者が実行する前提で手順を説明します。メールおよび Restore Agent は使用しない前提です。
VSC のバージョンは 4.2.1、英語環境なので UI が英語ですが勘弁してください。
バックアップは取得してある前提で、リストアするところから始めます。

  1. vSphere Client で対象の仮想マシンを右クリックし、[NetApp]->[Backup and Recovery]->[Single File Restore]をクリックします。
  2. [Source VM]と[Destination VM]にリストア対象の仮想マシンを選択し、メールアドレス欄にダミーのメールアドレスを入力します。このメールは管理者がリストアを実行する場合には使用しませんが、空欄にすることはできません。送れないメールアドレスであっても特にエラーなどは出ません。[Mount expiration]はデフォルトのままでOKです。
  3. [Limited Self-Service]を選択して[Next]をクリックします。
  4. リストアしたいバックアップを選択して[Next]をクリックします。
  5. 内容を確認して[Finish]をクリックします。これでリストア対象の仮想マシンにバックアップ当時の仮想ディスクが追加されます。
  6. リストア対象の仮想マシンにログインし、ディスクの管理画面を開きます。新しいオフラインのディスクが見えているはずです。ディスクを右クリックして、[Online]をクリックします。
  7. Windows Server のバージョンと設定によっては、自動的にドライブレターが割り当てられることもあります。その場合は★の手順までスキップしてください。割り当てられない場合はリストアしたいファイルが入っているパーティションの上で右クリックし、[Change Drive Letter and Paths...]をクリックします。
  8. [Add...]をクリックします。
  9. [Assign the following drive letter]を選択し、適当なドライブレターを選択して[OK]をクリックします。
  10. ★エクスプローラを開くと追加したディスクが表示されているはずです。目的のファイルをコピーしてリストアします。
  11. リストアが完了したら、vSphere Client に戻ってホーム画面から[NetApp]をクリックします。
  12. 左のメニューで[Backup and Recovery]->[Single File Restore]をクリックすると、右ペインにリストアセッションが表示されます。選択して、[Delete...]をクリックします。
  13. 警告画面が出ます。[Yes]をクリックします。
  14. [Recent Tasks]欄で、仮想マシンの構成変更とデータストアのアンマウントが完了したことを確認します。
  15. 仮想マシンでエクスプローラを開くとディスクが消えていることが確認できます。これで完了です。

2015年10月6日火曜日

ESXi 5.5 u3 に致命的なバグ!

(2015/10/07追記:早速パッチが出ました。→VMware ESXi 5.5, Patch Release ESXi550-201510001 (2133824))

ESXi 5.5 update 3 で、スナップショットの統合後に仮想マシンが停止するというパネェバグが出てます。

After Snapshot consolidation task, virtual machines running on VMware ESXi 5.5 Update 3 host fails with the error: Unexpected signal: 11 (2133118)

VADP を使ったバックアップをしている場合は必然的にバックアップの度に VMware snapshot の統合が行われているわけで、バグにあたる可能性極大です。回避策は無し!u2 にダウングレードするか、スナップショット取らない(統合しない)かしかありません!!u3 使っちゃダメ!絶対!!

2015年10月5日月曜日

VMware の便利リンク集

随時更新予定。

vSphere Client の各バージョンの直リンク一覧
Download URLs for VMware vSphere Client (2089791)
※MyVMwareログイン無しでダウンロード可能です。
各製品のバージョンとビルド番号の紐付け
Correlating VMware product build numbers to update levels (1014508)

2015年10月4日日曜日

NetApp の Virtual Storage Console (VSC) の挙動

バックアップの取得時間の速さについては各ベンダしのぎを削っていますが、仮想基盤上の仮想マシンのイメージバックアップに関しては、やはりストレージのスナップショットがダントツに速いです。中でも NetApp の Snapshot はバックアップとして保持し続けてもパフォーマンス劣化がほぼ無いのですんごくイイと思っています。Virtual Storage Console (VSC) というソフトを vCenter Server のプラグインとしてインストールして使います。専用のバックアップサーバとか Virtual Appliance を立てる必要が無いってのもイイですね。難点としては、バージョン 5.0 からファイルレベルでのリストアができなくなったこと。グローバルではそんなに需要無いのか知りませんが、日本では「ファイルレベルのリストアができること」は仕様書でしばられていることが非常に多いので、是非復活して欲しいです。ファイルレベルリストアが可能な 4.X も、最新の ONTAP に対応し続けているので、一部で(?)需要があるってことはわかってると思うんですけどね。

で、今回はとある案件で VSC が採用になり、VSC でのバックアップ・リストア設計と手順の確立を行わないといけなくなったのでお勉強中です。検証してわかったことをメモしておきます。申し訳ないですが初心者向け記事ではないので NetApp 用語とか VMware 用語とかいちいち説明しません。

前提条件は以下の通り。

  • NFS ボリューム1に仮想マシンが複数台ある。
  • ある特定の1仮想マシンは VSC バックアップ対象外。(vCenter Server。別途 Windows Server Backup でバックアップ)
  • バックアップ対象の仮想マシンは全台同時にバックアップする。
  • バックアップ前後でミドルウェアの停止・起動が必要なサーバがある。
  • バックアップ取得後、NFS ボリューム2に SnapMirror する。

検証環境はちょっと古くて vSphere はバージョン 5.1、VSC は 4.2.1、ONTAP は 8.2.1(c-mode) です。 前述した条件を満たすように以下の設定にしました。

  • NFS ボリューム1,2 の SnapMirror 関係を予め設定しておく。スケジューリングはしない。
  • VSC のジョブは1つで、対象としてデータストアではなく特定の1台を除いた仮想マシン全台を選択する。
  • VSC のジョブで、Initiate SnapMirror update と Perform VMware consistency snapshot にチェックを入れる。
  • ミドルウェアの停止・起動は VADP のカスタム静止スクリプトを使う。
    VSC にもバックアップ前後にスクリプトを実行する機能はありますが、その場合のスクリプトは VSC サーバ上に配置する必要があるので、対象サーバにリモート接続して処理を実行させるというのをバッチファイル内に実装する必要があります。一方 VADP のカスタム静止スクリプトは、それぞれのゲストOSの中に置くので、リモート接続する部分のコーディングをする必要がなくシンプルに実装できます。尚、VADP のカスタム静止スクリプトの実行タイミングは VMware snapshot の前後ですが、VSC のジョブでスクリプトを設定した場合の実行タイミングは VSC バックアップジョブの前後となります。

検証してわかったこと。

  • バックアップ処理の詳細なフロー。
    1. バックアップ対象全台の VMware snapshot の作成が一斉(数台ずつらしいが検証環境では少数だったので)に開始。VMware のタスクの Create snapshot の開始時刻。
      このとき、バックアップ対象になっていない仮想マシンは同じデータストア上にあっても VMware snapshot は作成開始されない。
    2. カスタム静止スクリプト(c:\windows\pre-freeze-script.bat)がある場合、実行。
    3. VMware snapshot が作成される。
    4. カスタム静止スクリプト(c:\windows\post-thaw-script.bat)がある場合、実行。
      このスクリプトによる状態の変化は VMware snapshot ファイルに書き込まれる。
    5. VMware snapshot 作成完了。VMware のタスクの Create snapshot の完了時刻。
      バックアップ対象全台の VMware snapshot 作成が完了状態になるまで、次のフェーズには進まない。
    6. NetApp Snapshot 作成。
      Snapshot はその仕様上ボリューム単位での取得なので、バックアップ対象であるか否かに関わらずボリューム上の全てが Snapshot に含まれる。
    7. VMware snapshot の削除開始→完了。
      VMware snapshot が存在していた間の変化が反映される。
    8. SnapMirror 用の Snapshot が作成される。
    9. SnapMirror。
  • つまり当たり前ですが VSC によるバックアップ取得時点の NetApp Snapshot 内のバックアップ対象仮想マシンは、VMware snapshot がある状態です。ただし、仮想マシンの電源が落ちていた場合は VMware snapshot の作成自体が行われないのでバックアップ対象仮想マシンであっても VMware snapshot はありません。SnapMirror は VMware snapshot の削除後に行われるので、SnapMirror 時点の NetApp Snapshot 内には、バックアップ対象であるかどうかに関わらず VMware snapshot はありません。
    NetApp の代理店サイトの説明ページなどで、SnapMirror が VMware snapshot 削除の前に行われるように記載されているものがありますが、それは間違っています。
  • VSC による NetApp Snapshot の名前は、直近のものが『smvi__ジョブ名_recent』で、それ以外は『smvi__ジョブ名_YYYYMMDDhhmmss』。
  • SnapMirror 時に作成される NetApp Snapshot の名前は、『snapmirror.』から始まる。
  • VMware snapshot の作成に失敗した場合でも NetApp Snapshot は取得され、VSC 的には成功とみなされる。
  • バックアップに関するログは vCenter Server のイベントログ(Application) にソース SMVI ででる。ログの内容に関わらずイベントIDは全て4096。 バックアップの開始は出ない。完了は VMware snapshot の削除完了後に Info で出る。SnapMirror に関するログは出ない。VMware snapshot に失敗したログは Warn で出る。リストアも開始は出ないが完了は Info で出る。
  • バックアップジョブを削除しても既に取得済みのバックアップデータには影響ない。
  • VSC によるリストア処理の詳細なフロー。
    1. 仮想マシンのパワーオフ。
    2. VSC 取得時点の NetApp Snapshot からのリストア。
    3. VMware snapshot を取得した時点に移動(Revert)する。※VMware snapshot の削除ではない。つまり、post-thaw-script.bat による変化や、その他 VMware snapshot が存在していた間に起きた更新を破棄して、pre-freeze-script.bat 終了時点に戻る。
    4. VMware shapshot を削除。直前で更新部分を破棄しているので反映されるものは何も無い。
    5. リストア実行時に、リストア完了後仮想マシンを再起動するチェックボックスにチェックを入れていた場合は仮想マシンのパワーオンが行われる。
  • バックアップもリストアも、NetApp Snapshot 関連の処理は容量に関わらず数秒で終わるので、所要時間は、カスタム静止スクリプト(バックアップ時のみ)、VMware snapshot 関連の処理、SnapMirror(バックアップ時のみ)、電源OFF/ON(リストア時のみ)の所要時間に依存して決まる。尚、リストアが高速化したのは cDOT になってから。よって、7-Mode 時代に書かれた VSC の説明記事ではリストアには容量に応じた時間がかかると書いてある。cDOT であれば VSC のバージョンは 4.X でも OK。

バックアップもリストアも、簡単に直感的に操作でき、しかも速いのですが、問題は SnapMirror の Source が死んだ場合にどうやってリストアするかですね。 これについて明確に説明してある情報が公式にも非公式にも見当たりません。
Tech OnTap のこちらの記事では、SnapMirror 関係を break して、ミラー先ボリュームをデータストアとしてマウントして、そこから仮想マシンを起動しているようですが、これだと静止点のデータでは無いはずです。そもそも仮想マシンがサーバではなくてデスクトップですし、システム領域の VSC バックアップしていないですし、静止点の確保については完全に無視なんですね。
今回検証している構成では、わざわざ VSC で VADP 連携して静止点をとったバックアップを SnapMirror しているのに、SnapMirror 先から起動する際に静止点ではないデータから起動していたら意味がないので、静止点まで戻る方法として以下の手順を考えました。

  1. 平常時に予め仮想マシンの名前(ホスト名ではなくインベントリ上に表示される名前)と配置を記録しておく。
    切替時に仮想マシンの登録しなおしが発生しますが、その際にウイザード中でデフォルトで設定される仮想マシン名は vmx ファイルのファイル名になります。後から仮想マシン名を変更した場合などはファイル名と仮想マシン名が異なっている場合があるので仮想マシン名をメモっておきましょう。メモっておかなかった場合や、メモが信用できない場合は、vmx ファイルの中の displayName が仮想マシン名なのでそれを確認しながら作業することになります。
  2. SnapMirror 関係を break する。
  3. NFS ボリューム2 を最後に VSC バックアップを行ったときの Snapshot(smvi__ジョブ名_recent) に SnapRestore する。
  4. NFS ボリューム1 にある仮想マシンを全てインベントリから削除。
    このとき、電源が入ったままの仮想マシンはインベントリから削除できません。 vCenter Server が生きていて、かつ普通に vSphere Client から電源を落とすことができれば落として削除してください。 既にかつてのデータストアとの接続が失われている場合は、vSphere Client や vim-cmd ではシャットダウンもパワーオフもエラーになってできないので、ESXi に ssh かコンソールでログインし、以下の方法でコマンドラインから落としてください。-t の引数は検証では soft でいけましたが、もし失敗したら hard、それも失敗したら force で実行してください。
    Sample Command Image
  5. vCenter Server を復旧させる。※vCenter Server も同じボリュームにあって死んでいる前提です。生きている場合はスキップ。
    1. vSphere Client で vCenter Server が配置されていた ESXi サーバに接続。
      尚、ESXi をロックダウンモードにしている場合は、一度コンソールまたは SSH で接続してロックダウンモードを解除しないと接続できませんので注意してください。以下がロックダウンモードの操作系コマンドです。
      vim-cmd -U dcui vimsvc/auth/lockdown_is_enabled ※確認コマンド
      vim-cmd -U dcui vimsvc/auth/lockdown_mode_exit ※無効にする
      vim-cmd -U dcui vimsvc/auth/lockdown_mode_enter ※有効にする
      
    2. NFS ボリューム2 のデータストアブラウザで vCenter Server の vmx ファイルを右クリックしてインベントリに登録。
      このとき、ウイザード中で聞かれる仮想マシン名は平常時に記録しておいたものを参照して違っていれば修正すること。
    3. vCenter Server を Windows Server Backup からリストア(手順省略)。
    4. vCenter Server を 再起動。ロックダウンモードを解除した場合は元に戻す。
  6. vSphere Client で vCenter Server に接続。
  7. NFS ボリューム2 のデータストアブラウザを開き、各サーバの vmx ファイルを右クリックして、平常時に記録しておいた仮想マシン名で適切な ESXi サーバ(またはDCやリソースプール)を指定してインベントリに登録していく。
  8. 各仮想マシンのスナップショットマネージャを開き、snapshot 作成時点に『移動(Revert)』し、完了したら snapshot を削除する。
  9. 各仮想マシンを起動する。

上記の手順は実際検証してみてうまくいっています。が、本番もこれを全部手でやるか、もしくはスクリプトを自力で作成しておかないといけないんでしょうか・・・。何かもっと簡単な方法は無いんだろうか。しかも上記の手順は全台を1つのバックアップジョブでバックアップしている場合です。複数のジョブに分けていた場合は、静止点がある Snapshot が1つでないので、SnapRestore で一気に戻すということができません。とりあえず一番最後に実行されたジョブの Snapshot に SnapRestore して、それより古い Snapshot にしか静止点が無いサーバは、Snapshot からファイル単位の SnapRestore または FlexClone ですかね・・・?どなたかアドバイスあればお願いします。m(_ _)m

2015年10月2日金曜日

Movable Type からのインポート

宣言通りの方法でインポートしたんですけど、改行が<br/>に変換されてしまって二重になり、それだけならまだ行間が広いなーってだけでいいんですが、<pre>タグの中とか、テーブルタグとかリストタグとかのタグとタグの間の本来何も書いてはいけないところとかまで容赦なく入っているので、こつこつ1記事ずつ<br/>置換して見直しして公開していってます・・・。Movable Type で書いていたときに、HTML 手書きするモードで書いたものは全滅です。HTML 使わないタイプのエディタで書いた記事1個しかないwwwなので全部公開するにはかなり時間がかかりそうです。それと、全角の~も化けて?に変換されています。見つけたら修正しているつもりですが、残っていたらすみません。ご指摘いただくか脳内変換してください。