FC2ブログ
基盤系インフラSE 4年目 技術備忘録 派遣社員(特定派遣)

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告|
  3. トラックバック(-)|
  4. コメント(-)

この記事を閲覧するにはパスワードが必要です
パスワード入力
  1. 2015/10/31(土) 14:36:41|
  2. 未分類|
  3. トラックバック(-)|
  4. コメント(-)

Vmware snapshot 仕組み

■問合せで、イベントログでエラーはいてるんだけど!ってのがあっていまいちピンとこなかったのでまとめ
 →snapshot作成中、Disk I/O の静止が行われるのでその間、既存ディスク(-flat.vmdk)へのアクセスはエラーになる。
   snapshotが削除されるまで、deltaファイルに書き込まれる。-falt.vmdk へは Read Only

<あらゆるところから引用>

スナップショットの仕組みは意外と?シンプルである。スナップショット取得前までに使用していた .vmdkファイルへの書込み(更新)を停止し、差分を -delta.vmdkファイルに書込みを行うことで実現している。現在のゲストOSの状態は、 .vmdkファイルと -delta.vmdkファイルで保持しているデータを組合せたものになる。

.vmdkファイル ・・・ スナップショットを取得すると更新停止
-delta.vmdkファイル ・・・ スナップショットを取得すると生成、以降このファイルのみを更新


この仕組みであると、スナップショットを取得する度に -delta.vmdkファイルが生成される。現在のゲストOSの状態が複数ファイルで保持されるようになるため、当然パフォーマンスの低下が発生する。VMware社では、スナップショットの個数を2~3個までにすることを推奨している。また、スナップショットを取得したまま24~72時間以上放置しないように警告している。

では、スナップショットを取得した後どうするか。それが削除や統合である。 -delta.vmdkファイルの内容を .vmdkファイルにマージしてくれる。なお、削除を行った際に、差分ファイルが上手く生成されず、ゴミファイルが残ってしまうことがある。そのため、VShere5から統合という新しい仕組みが追加された。統合では差分ディスクを検索し、データ依存関係に違反しないように .vmdkファイルや -delta.vmdkファイルをマージしてくれる。



仮想ディスクの構成:

仮想マシンにある仮想ディスクを作成すると、仮想マシン名-flat.vmdk というファイル
が仮想マシンの構成フォルダ内に作成されます。

30GB の仮想ディスクを作成した場合、仮想マシン名-flat.vmdk というファイルが、
30GB の容量を保持します。

スナップショットを取得していない場合は、このファイルが仮想マシンのファイルの内容を
保時します。仮想マシンの情報が更新されてもこのファイルの容量変動しません。

スナップショットを取得した場合、差分ファイルとして「仮想マシン名-******-delta.vmdk」
が作成されます。

このとき仮想マシンは、-flat.vmdk と差分情報である、******-delta.vmdk の両方
の情報を併せて仮想ディスクの情報を保持しています。

この時点で現在の OS の情報は、、******-delta.vmdk + 仮想マシン-flat.vmdkで情
報を保持します。以降仮想マシン-flat.vmdk のファイルは、更新されません。
つまり、スナップショットを取得した時点の情報を仮想マシン-flat.vmdk が持ちます。
情報更新がされるたびに ******-delta.vmdk のファイル情報が更新されていきます。

******-delta.vmdk は情報が更新されるたびに容量が増加していきます。

スナップショットが作成された時点では、******-delta.vmdk の容量は約 16MB と大容
量ではありません。しかし、ゲスト OS 内で情報が更新される(新規作成、修正、削除な
ど)と差分ファイルの容量は、増加していき、最大で仮想ディスクに設定した容量(仮想デ
ィスクが 30GB の場合は、30GB まで)までファイル容量が増加します。

作成された差分ファイルは次のスナップショットが取得されるまで、情報が更新されるたびに
増加します。次のスナップショットが作成されると、今度は、情報更新の度にその時に作成
された ******-delta.vmdk のファイルの容量が増加します。


スナップショットの削除の仕組み:

スナップショットの削除をおこうなう際、どの世代のスナップショットを削除するかによって必要な容量は
異なります。

例:
2世代のスナップショットを保持する仮想ディスクを想定:

構成ファイルの内訳:

 ・ オリジナル情報----------------------Virtualmachine-flat.vmdk (30GB)

 ・ 1世代目のスナップショット情報----------Virtualmachine-00001-delta.vmdk (5GB)

 ・ 2世代目のスナップショット情報----------Virtualmachine-00002-delta.vmdk (2GB)

・ 現在のOSイメージ情報---------------Virtualmachine-00003-delta.vmdk(15GB)


この状態で直近のスナップショットである 2世代目のスナップショット情報を削除した場合は、
Virtualmachine-00003-delta.vmdk の情報を Virtualmachine-00002-delta.vmdk へ結合
した後に Virtualmachine-00003-delta.vmdk が破棄されます。
そして現在の OS イメージ情報を Virtualmachine-00002-delta.vmdk が保持します。この後は、
Virtualmachine-00002-delta.vmdk が情報が更新されるたびにファイルの容量が増加していきます。

このとき結合前に、Virtualmachine-00003-delta.vmdk の内容をコピーする領域として
Virtualmachine00003-delta.vmdk の容量が必要となり、 15GB が空き容量が必要になります。

1世代目のスナップショット情報を取得したスナップショットを削除した場合は、
Virtualmachine-00001-delta.vmdk が flat.vmdk に情報を結合した後に
Virtualmachine-00001-delta.vmdk が破棄されます。

元のディスクに結合する場合は、直接結合を行うため空き容量は不要です。

またスナップショットマネージャで”すべて削除”を実施する場合は、それぞれの世代に対して結合を
行うため必要な空き容量が増加します。

①Virtualmachine-00003-delta.vmdk が Virtualmachine-00002-delta.vmdk と結合(空き容量:15GB)
②Virtualmachine-00003-delta.vmdk が Virtualmachine-00001-delta.vmdk と結合(空き容量:15GB)
③Virtualmachine-00002-delta.vmdk が Virtualmachine-00001-delta.vmdk と結合(空き容量: 2GB)

合計、① + ② + ③  = 32GB が必要となります。

”すべて削除”に必要な空き容量が確保できない場合は、スナップショットを1世代毎に削除することで
対応します。



snap1.png

snap2.png

  1. 2015/10/31(土) 01:07:11|
  2. VMware|
  3. トラックバック(-)|
  4. コメント:0

VMware UUID

■今日の個人的な検証(仕事しろよ)でわかったこと

・DirectorでVMを作成すると、vSphere上に 仮想マシン名(UUIDっぽいもの)が作成・表示される。
 →()内は別にそのVMの本当のUUIDってわけじゃなくてあくまでvCenter(vSphere)上で一意の文字列(わかりやすくいつもUUIDと呼んでいるが)をつくってるだけっぽい ※作成直後に、.vmx 内のUUIDを確認したが異なっていたからそう思っただけで根拠はない仮にvCenterUUIDと呼ぶ。

・Director上でのVMのvApp移動の挙動
 →一度VMをクローンし、移動先のvAppで新規でクローンしたVMを作成する、その後 元のvAppからVMを削除する
 →VMのUUIDは、vSphere上の表記(vCenterUUID)は変わっているが、VMのUUIDは引き継がれていた。(.vmxファイルを確認)
 →vmxファイルかどこかの設定ファイルで、UUID設定値がkeepになっているっぽい 新規の場合はactive
  Storage vMotion + 再起動とか、sysprepとかでUUID変更はされなかった。


■問題となったバックアップ挙動

バックアップソフトは、vCenter(vSphere上の仮想マシン名)をPolicyに登録している。
その後、Policyで設定された時刻にそのVMのUUIDに紐付いたデータストアからバックアップを始める。
バックアップソフトで、旧仮想マシン名:naoki UUID:AAA をとってくださいよというPolicyが登録されている。

新仮想マシン名をnaoki2に変更しちゃうと 仮想マシン名違うのにUUIDは同じなので、まずバックアップソフトに仮想マシン:naoki2をとってくださいよという指令が拒否されてPolicy(バックアップするよというスケジュール)に反映されない。

でもこれはただPolicyに反映するのに失敗するだけで、例え仮想マシン名が変わっても、そのUUIDのものをバックアップしにいく。
これが今回、Policyに登録失敗直後にスケジュールからはずれるという命令がスクリプト内に入っていたのでそのままではバックアップされないこととなり、手動でスケジュールさせた。

ただこの状態だと例えバックアップに成功したとしても、既存のVMに上書きリストアができない(仮想マシン名が違うから)

その後、旧仮想マシン名:naoki UUID:AAA という情報をバックアップソフト上から削除(正確には削除ではないが)し、
新仮想マシン名:naoki2 UUID:AAA の情報を Policyに反映させることで、以後バックアップはとれるようになった。

なんとなく仕組みはわかったがバックアップソフトの挙動なんて知っても製品ごとに違うから他の現場であんまり役に立ちそうに無いg・・・



■その後わかったこと

Director上から仮想マシン名を変更すると、vmxファイル内の
displayName = ****
が変更される。その名の通り、vSphere上の表記が変更される。
が、データストア上のファイル名や設定値は元の仮想マシン名のまま。

<引用>
わかりやすい→http://www.rem-system.com/post-1000/#i

1.仮想マシン保存先のフォルダ・ファイル名が変更されない

仮想マシンは、vSphere Client (最近はvSphere Web Clientですね)から表示名を変更することができます。
(就業先ではvCloud Director上から仮想マシン名を簡単に変更できる)
単純なオペレーションで、簡単に変更できるので、後から名前を変更すればいいと考え、適当な名前を付けておくと、後々困ることになります。
というのも変更されるのはvSphere Clientから見た場合の表示名のみで、実際に仮想マシンが保存されているフォルダ・ファイル名や構成ファイルは変更されないからです。
VMWareの仮想マシンは全てデータストアという領域に保存されています。
データストアはvmfsという排他制御機能を持つ、特別なファイルシステムでフォーマットされた仮想マシンの格納領域です。
仮想マシンは、このデータストアに配置され、仮想マシンごとにマシン名が付与されたフォルダ・ファイルがが作成されます。
例えば、vmge01 という仮想マシンを作成した場合、データストアにはvmge01という名前のフォルダが作成され、このフォルダに仮想マシンの構成ファイルや仮想ディスクファイルが保存されます。

vSphere Clientから表示名を変更して、見かけ上は仮想マシン名が変更されたように見えても、このファイル名・フォルダ名・構成ファイルの内容は変更されないのが意外と盲点となっています。
例えば、仮想マシン:vmge01の表示名を vmge02に変更したとしても、データストアのフォルダ名とフォルダに含まれるファイル名はvmge01のままになります。
仮想マシンの台数が増えてくると、フォルダ・ファイル名と表示名の整合性がとれませんので、かなり混乱することになります。
そこで表示名を変更した後に、フォルダ・ファイル名を併せて変更する手順が必要となります。

<引用ここまで>

しかしこれによって何か不都合がでているわけではないので、別にそのままでいいのでは?
管理者が混乱するだけで。あくまで参考がてら。



  1. 2015/10/31(土) 00:45:58|
  2. VMware|
  3. トラックバック(-)|
  4. コメント:0

n1kについて

あしたかく



n1k2.png

http://www.cisco.com/web/JP/product/hs/switches/nexus1000/prodlit/data_sheet_c78-492971.html


■疑問

ホスト間のvMotionでも、一回VSMとvCenterで通信している?
→管理しているのはあくまでVSM?VEM同士では同期はとっていない。
→Port Profileを管理しているのはVSMで、VSMとvCenterが常に繋がっていないといけないのか


■2015.12.03 追記
VSMとvCenterが疎通がとれていない状態だと、ESXi間の仮想マシンの疎通がとれなくなる。
同じESXi上の仮想マシンの疎通は可能だった。
つまりDRSなどで、別ESXiに移ってしまった場合、仮想マシン間の疎通ができなくなる。

・・・VSMって重要な役割なんだな(他人事)

  1. 2015/10/28(水) 01:04:24|
  2. Cisco UCS / Nexus1000v|
  3. トラックバック(-)|
  4. コメント:0

DRSの仕組みについて現時点まとめ

※DRSとHAの関係

現象
・CPUのMHzがなんたら~で特定ESXi上のVMをパワーオンできない
→リソース不足(パワーオンしているVMらの予約値から計算できる)
→設定となっているのは、HAのアドミッションコントロールの設定
 フェイルオーバーに必要なリソースをあらかじめ予約、それが確保できない場合はパワーオン動作を許可しない

・DRSの機能が著しく低下~っていうイベントエラーログが大量に出る
→上に記述

・各ESXiホストに、リソースの偏りがでているように見える
→そもそもDRSって何の目的であるのか?



<引用>
■アドミッションコントロール

VMware HAによって保護された仮想マシンがほかのESXiホストで確実にフェイルオーバーできるようにするためにはクラスタの各ESXiホストにフェイルオーバー用に予備リソースを確保する必要があります。ホスト上で予備リソースを確保できないと判断した場合、仮想マシンのパワーオンなどの追加リソースの消費を制限します。これをアドミッションコントロールといいリソース不足のときには次の動作が禁止されます。

○仮想マシンのパワーオン
○ホスト、クラスタ、、リソースプールへの仮想マシンの移行
○仮想マシンのCPUやメモリの予約値の増加

また、アドミッションコントロールを行うために予備リソースを確保する方法として次の3つのポリシーから選択可能です。

○ホスト障害のクラスタ許容台数
○フェイルオーバーの予備予約容量として予約されたクラスタリソースの割合
○フェイルオーバーホストの指定

drs1.png


http://www.unix-power.net/vmware/adcontrol_55.html

http://itmemo.digi2.jp/allCont/esxi5page/ESXi5HaSetting.html

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2081795

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2088299

http://itmemo.digi2.jp/allCont/esxi5page/ESXi5DrsValidate.html#sec1


<KBで断言してる・・・>

Cause

DRS プロセスは、移行のコストが得られるメリットよりも大きい場合は、同一クラスタ内の他のホストへの仮想マシンの移行をしないと判断する場合があります。現在稼働中のホストで実行中の仮想マシンが要求するリソースを十分確保できる場合、負荷分散のための移行を行うことはデメリットが発生するだけであり、これに伴うメリットはありません。


Resolution

DRS の主な目的は、クラスタ内の仮想マシンに対してそれらの仮想マシンが要求するリソースを確保できる手段を提供することです。DRS は、クラスタ内のホスト間でリソースの消費を均等に分散させることを目的として設計されているわけではありません。
実行中の仮想マシンが要求しているリソースをそのホスト上で 100% 提供できる場合、そのホストのメモリおよび CPU の使用率が高くなったとしても、必ずしも仮想マシンを移行する必要はありません。この結果、クラスタ内のリソース消費が不均衡な状態になったとしても、仮想マシンのパフォーマンス低下が見られない限り、特に問題ではありません。

DRS クラスタ内のホストがその上で動作している仮想マシンが要求するリソースを提供できない場合、DRS は要求されたリソースを提供できる他のホストにその仮想マシンを移行します。


drs2.png
drs3.png
drs4.png

ここの設定か


drs5.png



では、どういう設定にするのが適切か。
以下自論。

■ HA発生時のときの為にフェイルオーバー用のリソースを確保する必要があるかどうか
  → HAを有効にしている時点で、同じクラスタ内の空きのあるホストに移るのでは?
   →もしそうなら、アドミッションコントロールを有効化にする必要はあるのか?

■アドミッションコントロールのエラーは、リソース不足の予兆であると考えるか
  → これ以上、VMを乗せるとフェイルオーバーできないよという警告



・・・いずれにしても、アドミッションコントロールのリソース予約値の%下げればいいんじゃね。


↓全部ここに詳しく書いてある。P18~
http://pubs.vmware.com/vsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-availability-guide.pdf

  1. 2015/10/27(火) 20:49:15|
  2. VMware|
  3. トラックバック(-)|
  4. コメント:0

UCS B-Series Blade Server の交換手順

【今日の作業】 UCSMからBlade Server をはずし、メモリ交換

UCS B-Series Blade Server の交換手順

■作業手順



【お客様作業】

1. OS shutdown



2. 該当サーバーに適用されている Service Profile の Disassociation 実施、完了を待つ


(Servers タブ配下 servers > Service Profile 配下該当 Service Profile を選択、
右画面 General タブを選択、Actions 項目内、Disassociation Service Profile を選択、確認画面で OK)



3. 該当サーバーの Server の Decommission 実施、完了を待つ


(Equipment > Chassis > Chassis X > Servers > Server X、
右画面 Action 項目内server maintenance をクリック、Maintenance Server 画面で、Decommission を選択して、確認画面で OK)



4. UCS Manager 上で該当サーバースロットが赤くなっていることを確認

Needs Resolutionと表示される。



【FE作業】

5. 該当サーバーをシャーシから抜く



6. Top cover を開ける



7. 元のブレードから、CPU、Memory、Adapter Card、HDD を抜く



8. 交換用ブレードに、CPU、Memory、Adapter Card、HDD を挿す



9. Top cover を閉める



10. 該当サーバーをシャーシに戻す



【お客様作業】

11. Equipment タブから該当サーバーを選択する。
Actions より Reacknowledge を選択、確認画面で OK する。
該当サーバーが Unassociated のステータスとなるのを待つ



12. 該当サーバーに Service Profile を Association し、完了(Power Off もしくは OK)を待つ。

(Servers タブ配下 servers > Service Profile 配下該当 Service Profile を選択、
右画面 General タブを選択、Actions 項目内、Change Service Profile Associationを 選択、Associate Service Profile 画面で該当サーバーを選択、確認画面で OK をする)



※「Associate Server Profile 」選択後、自動でサーバがBootされる。びっくり

UCS B-Series 各コンポーネントの交換手順まとめ

  1. 2015/10/27(火) 00:51:48|
  2. Cisco UCS / Nexus1000v|
  3. トラックバック(-)|
  4. コメント:0

Active Directory サイト間レプリケーション検証

この記事を閲覧するにはパスワードが必要です
パスワード入力
  1. 2015/10/25(日) 18:48:23|
  2. WindowsServer|
  3. トラックバック(-)|
  4. コメント(-)

Update Sequence Number

編集中

■ADのsnapshotの問題

sample1.png

sample2.png


■ロールバックできなくなったときの対応

■どういう場合?ユーザ削除のときだけ?

時刻ずれについてのまとめ

ac5.png



ac2.png

ac3.png


DCは内部にデータベースを持っており、
データが何処まで更新されたかを管理する更新シーケンス番号(USN)を持っている

DCは通常複数台でレプリケーションする

不用意にスナップショットを復元すると古いUSNのデータベースと
新しいUSNのデータベース間で競合が発生する




注:ドメイン コントローラとして実行している仮想マシンのスナップショットを取ることは推奨されません。Windows Server 2012 では、スナップショットの作成をサポートする変更が行われています。詳細は、Microsoft TechNet の記事「Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)」を参照してください。仮想マシンが Windows ドメイン コントローラを実行している場合、スナップショットは Microsoft によってサポートされません。詳細については、「Virtualizing a Windows Active Directory Domain Infrastructure」ホワイト ペーパーを参照してください。

詳細については、次の関連する Microsoft サポート技術情報の記事を参照してください。
Things to consider when you host Active Directory domain controllers in virtual hosting environments.
How to detect and recover from a USN rollback in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2
Active Directory ドメイン コントローラにおける FSMO の配置と最適化に関する情報については、Microsoft のナレッジ ベースの記事 223346 を参照してください。

注:このリンクは、2014 年 7 月 30 日時点のものです。この記事のリンクが切れているのに気づいた場合はご連絡ください。VMware の担当者がリンクを更新します。



WinSV2012では、
1. 仮想マシンに世代管理のための「VM-Generation ID」を付与
2. スナップショットから復元した場合、このVM-Generation IDを更新する
3. DC起動時にVM-Generation IDの変更を検知して競合を防ぐ



Hyper-Vなどの仮想マシン上にActive Directoryのドメイン・コントローラ(DC)をインストールすることは可能だが、その運用には注意する必要がある。Active Directoryは通常、複数のDC間でデータベースを複製しながら動作しているが、DCが動作している仮想マシンを複製したり、スナップショットで(もしくはバックアップを使って)環境を以前の状態に戻したりすると、各DCが持つデータベースの内容に矛盾や不整合が生じてしまうからだ。DCは、データベースの更新状態(バージョン)を表すために「USN(Update Sequence Number)」というシーケンス番号カウンタを持っており、データベースに変更が生じた場合は、変更内容と共にこのUSN番号をほかのDCに通知している(データを送信後、USN番号を1つ増加させる)。受信した側のDCはこのUSN番号を見ることにより、どの要求までを受信/処理したかを判断している。

 DCをインストールした仮想マシンをスナップショットやバックアップからの復元などで以前の状態に戻すと、USN番号が元に戻ってしまい(USNのロールバック)、ほかのDCから見るとすでに受信済みのUSN番号(と、新しいデータベース更新要求)をまた受信することになる。これではデータベースの正当性を保証できないので、USNがロールバックしていることを検出するとActive Directoryの複製を停止する。この結果、各DCのデータベース内容に矛盾が生じたり、残留オブジェクト(特定のDC上にのみ存在し、正しく複製されていないオブジェクト)が発生したりする。このような問題が発生するため、仮想マシンに対するスナップショットからの復元などの操作は基本的には禁止されている。DCの障害などで復旧が必要な場合は、定期的なDCバックアップから復元モードを使って戻すといった操作を行うことになっている。
@IT

  1. 2015/10/25(日) 10:54:34|
  2. WindowsServer|
  3. トラックバック(-)|
  4. コメント:0

運用

この記事を閲覧するにはパスワードが必要です
パスワード入力
  1. 2015/10/22(木) 00:16:18|
  2. 未分類|
  3. トラックバック(-)|
  4. コメント(-)

あしたかく!

WP_000973.jpg

UCS-design-N1K-ieorg1.png
  1. 2015/10/19(月) 01:56:01|
  2. Cisco UCS / Nexus1000v|
  3. トラックバック(-)|
  4. コメント:0
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。