VVMware 2015 セッションレポート⑤

本日はVMworld最終日でした。来年のVMworldはラスベガスで開催予定です。
最終日でもブレイクアウトセッションは行われており、既存のモノに加えて、アンコールのセッションなども行われています。

EUC4842 – Technical Deep Dive on Horizon Air Desktops and Applications
Horizon Airの技術的な解説セッションです。はVMwareが提供するDaaSであり、セキュリティ、デバイスの自由、エンタープライズな統合、ユーザエクスペリエンス、ティア個別のロールを提供します。Horion Airでは完全なVDIデスクトップ、ホスト型のアプリケーション、共有デスクトップによりユーザの求める全てのケースに対応することを可能にします。基本的なアーキテクチャとしては世界各地に散らばる共有リソースに対してTenantのアプリケーションがAPI経由でリソースマネジャーにアクセスし、各ユーザに仮想デスクトップを提供します。日本ではサービス展開が5月に始まったばかりのモノですが、このようなサービスは技術的な部分まで把握しないと不安が残るため、利便性だけではなく日本でもこのような技術セッションをもっと展開していくことが重要なのではないでしょうか。

INF5432 Infrastructure as Code – Ban Snowflake Deployments
実際にDevOpsな開発を行うためのデモセッションでした。インフラストラクチャをシンプルなコードで扱えるようにし、そのコードをPuppetで管理、環境へのデプロイを容易にするということが主な目的です。さらに、コードで標準かされていることで、それぞれのサーバでスノーフレークのように少しずつ構成が異なるということを避けることができます。また手動での変更が行われていたとしても、その変更はコードとの差異として現れ、どこの、何か問題になっているかを明確にできる、そしてデプロイが自動化されることで、トラブルの主な原因である人的要因を減らすことができます。このインフラストラクチャをコードとして扱うデモを実際に見ることでその利点を理解することのできるセッションとなっていました。

STO5937 Backup and Recovery with VMware vSphere Data Protection: Technical Walkthrough and Best Practices
vSphere Data Protectionの基本的な機能紹介とベストプラクティスを紹介するセッションです。まず初めにVer6.0での主な機能として簡単に次の機能が紹介されました、バックアップのレプリケーションが可能、SQL Server、Exchange、SharePointに関してアプリケーション用のエージェントで処理が可能、このエージェントで物理マシンもバックアップ可能、セルフサービスなファイルリストア、緊急用のホストへの直接リストアが可能。
そしてEMC AvamarがベースになっているVDPの仮想アプライアンスをデプロイするときの構成や重複排除のかかり方、Avamar、Data Domainとの連携などが紹介されました。また、上記の機能を実際に設定するデモも行われました。ベストプラクティスとしては外部プロキシの構成やVDPアプライアンスをPower Offで落としてしまうと不必要にチェクポイントまで戻ることがある、スナップショットの取り扱いなどを解説していました。
Veeam製品を扱っている関係上いろいろ思うことはありましたが、ここではセッションの紹介にとどめておきたいと思います。

タグ:

VMworld 2015 セッションレポート④

本日はSolution Exchange最終日でした。VMworld Partyもあり、盛り上がりも最高潮でした。
そんな中、今日もブレイクアウトセッション紹介していきます。

SDDC6282-SPO Using vSphere tags for advanced policy-driven data protection
データ保護をポリシーで行うためにどうするか?という課題にvSphereのタグを活用しましょうというセッションです。バックアップ運用環境に影響があるものですので、仮想環境を理解している管理者が構成を行うべきです。しかし、大規模環境やマルチテナントな環境の場合、管理者のみでは対応が難しくなってきます。そこで、データ保護のポリシーをタグで各VMのオーナが指定できるようにし、それに合わせてデータ保護の設定を行っていこうという内容でした。Veeamのセッションであるため詳細は別ブログの方で展開予定です。

STO4649 Virtual Volumes Technical Deep Dive
VVOLの技術的な部分を詳細に紹介するセッションです。VVOLがどのようなことかといったことはもちろんのこと、VASA Providerの詳細な動作、Protocol Endpointがなぜ必要なのか、従来のスナップショットとVVOLの場合のスナップショットの動作の比較など技術的な部分を詳細に紹介していました。

NET5615 Simplify your Disaster Recovery Planning with NSX and Site Recovery Manager
NSXとSRMを用いて災害対策DRを行うための要件とアーキテクチャを解説するセッションです。従来の災害対策と比較し、NSX+SRMならばどのような災害対策が可能か、またそのデモを交えて紹介していました。従来の災害対策は効果であり、複雑であり、テストが十分に行ず信頼性に不安がありました。特にネットワークは複雑で手動での再設定が必要な部分が多く、この点が大きな問題です。SRMでもネットワーク部分についてはそこまで触れられていませんでした。そこでNSXでネットワーク仮想化を行い、Cross vCenter NSX機能を活用しシンプルなレプリケーション実現しましょうという内容でした。

STO5906 Virtual SAN Technical Deep Dive and What’s New
タイトルの通りVirutal SANの技術的な解説と新機能の紹介セッションです。現在のストレージの動向をハイパーコンバージドインフラストラクチャを中心に紹介していき、EVO:RAILならば簡単に、Virtual SANならばより柔軟に使用できることをアピール、概要を説明していました。目玉の新機能としては大きく3つ、データ保護、管理の改善、サポートハードウェアの追加がありましたが、中心となっていたのはデータ保護の部分です。RPO=0のサイトレベルでの保護を提供するストレッチドクラスタ、ROBO用の2ノードオプション、Oracle RACやExchange DAG、SQL Server Always on可用性グループのサポートに注目が集まっていました。

タグ:

VMworld 2015 セッションレポート③

さて本日もブレイクアウトセッションの様子を紹介していて行きたいと思います。

INF4853 Docker Containers on vSphere: Paformance Deep Dive
まず、こちらのセッションはDockerのコンテナをvSphere上で実行した場合のパフォーマンスを様々な視点から評価したものなのですが、とてもよくできていました。どのような点が良かったかといいますと、その検証内容が細かく触れられている点です。どのようなベンチマークをどのような方法で、またvSphere上の場合にはVMとして分けた場合や一つのVMにまとめた場合などそれぞれの条件が細かく触れられており、とても説得力のあるものになっていました。気になる結果を簡単にまとめますと、vSphere上で実行することのオーバーヘッドは小さく、スケールアウトな構成の場合にはvSphere上の場合、リソースが共有されることの効果でよりパフォーマンスが上がることもあるという興味深い結果になっていました。

INF4534 5 Functions of Software-Defined Availability
このセッションではvSphere HAやDRSといった機能でどのように可用性を実現するか、またそれぞれの機能がどのようなオペレーションを行っているのかという内容で、各機能の設定項目等の解説はもちろんのこと、HA時のタイムアウトで、どこで障害が発生したでどの程度タイミングに差が発生するのかといった詳細な内容まで触れられていました。

HBC6027 VMware vCloud Air + Google Cloud Platform = The Best of Both Clouds for Enterprises
このセッションではvCloud Air経由で利用できるGoolgle CloudのプラットフォームであるStorageやBigQuery、Datastore、DNSに関して紹介していました。もう少々技術的内容も期待していたのですが、基本的な部分の解説とデモで構成された普通の紹介プレゼンテーションとなっていました。

SDDC6281-SPO Veeam Availability Suite v9 Deep Dive
弊社取扱い製品であるVeeamのセッションです。小さい方の講演会場であったということもありますが、事前登録で既に満杯になっており、当日参加の列も長く伸びていました。内容についてはV9の新機能に関するものであり、詳細は弊社別ブログにて展開させていただく予定です。

タグ:

VMworld 2015 セッションレポート②

本日もVMworld 2015のレポートを簡単にですがさせていただきます。ゼネラルセッションもはじまり、いよいよ本格的になってきたVMworldです。今回のテーマであるReady for Anyについて、クラウド、アプリケーション、デバイスに対してReadyを提供するといった流れで行われました。ただゼネラルセッションの内容は色々な方が展開してくださっていると思いますので、ここでは変わらずブレイクアウトセッションの内容を紹介していきたいと思います。

  • VAPP6009 Virtualizing an application when the vender syas “no”
  • Mission Community Hospital様の事例を元に、病院で使われているクリティカルなアプリケーションの仮想化にどのように対応したというセッションでした。ただ、内容としては通常のクリティカルなアプリケーションと同様に仮想化した場合のボトルネックをストレージのI/Oになってくるため、その部分をDataCore SoftawareのSDSで解決し、問題なく使用できアプリの開発、テストも簡単になりましたといった内容でした。

  • HBC5008 vCloud Air Disaster Recovery Technical Deep Dive
  • vCloud Airの災害対策機能のレプリケーションの技術セッションです。このセッションではvCloud Air Disaster Recovery機能の概要からSRMとの連携、フェイルオーバーする際のAD等の注意点も含め解説指定ました。会場の雰囲気としては質問も活発でvCloud Airのこれからに注目しているようでした。

  • BCO6685-SPO Hyperconverged Infrastructure: Potection and Backup Refresh
  • SimpliVityのハイパーコンバージドインフラストラクチャで既存のバックアップから脱出しようという旨のセッションです。前半は既存のエージェントバックアップ、Veeamのようなエージェントレスなバックアップ、ストレージなどのスナップショットとの比較、後半はデモというような流れでした。ハイパーコンバージドインフラストラクチャでは各ノードに複製を作成し簡単にデータ保護が可能になりますが、独自の技術が盛り込まれるためベンダーロックイン等で逆に柔軟性が損なわれないか心配なところです。

  • STO5475 Harnessing th Power of vStorage API for Data Protection: Lessons Learned and Best Practies Developed from Benchmarking Backup Solutions
  • Veritasの方がvStorage API Data Protectionを使用したバックアップソリューションのベンチマークを行いましたというセッションです。1時間のセッションですのでそこまで細かくはなく基本的にVeritas製品押しのセッションになっていました。

    タグ:

    VMworld 2015セッションレポート①

    今年も、サンフランシスコで行われているVMworldを視察しに来ています。フェイスブックの方では簡単な雰囲気等をご紹介していますが、ブログではセッション情報等を展開させていただきます。

    本日はまだ、ユーザ向けのジェネラルセッションはありませんでしたが、クイックタイムセッションを4つ受講してきました。それぞれ簡単にですが紹介させていただきます。

  • STO4650-QT Five Common Customer Use Cases for Virtual SAN
  • このセッションではVMware Virtual SAN(VSAN)を以下の5つのケースで使用する場合の一般的な構成などを紹介していました。
    ・運用環境
    ・管理クラスタ
    ・ROBO
    ・DMZ
    ・開発環境
    例えば管理クラスタ環境では、3から4ホストで、シングルCPUのホストを使用するケースも少なくないといった一般的な展開例やesxcliからVSANを作成する方法などを解説していました。

  • MGT6522-QT Enabling the Emerging World of DevOps and Containers
  • このセッションではvRealise Code Streamにより開発サイクルをなぜ高速にできるのかといった点を紹介していました。

  • NET6615-QT Extending the the Power of Software-Defined Networking to the Retail Branch
  • NSX+CloudGenixでSoftware Defined WANを構築し、Palo Altoをセキュリティ、Arkinを可視化のために使用しているColumnbia様の事例を紹介していました。どのように、各店舗のサーバとデータセンターをWAN経由でつなぎ、効率的なソフトウェアデファインドな管理を実現しているのか、実際のコンソール画面等も含め詳細な報告になっていました。

  • CNA5983-QT Accelerating Innovation with Microservice
  • Microserviceな考え方が、開発でどのような立ち位置なのか、Microserviceでどのようなポイントが重要になってくるのか、またMicroserviceだけではなく、DevOpsや自動化、統合により開発全体を高速していく点が重要になってくるといった内容を解説していました

    今後それぞれのセッション内容等を詳細なブログとして展開予定です。

    タグ:

    仮想マシンにWindows 10をインストールしてみました。

    7月29日にWindows 10がリリースされましたので、早速、vSphere上にインストールしてみようと思います。今回使用しているのは、vSphere 6です。vSphere 6ではすでにWindows 10をサポートしています。win10_01

    まずは、Windows 10のISOをダウンロードしてきます。Windows 10 Enterprise 64bitの評価版をダウンロードしました。

    ファイルサイズは、3.51GBでした。
    win10_02

    では、早速、作成した仮想マシンをパワーオンしてインストールを進めていきます。
    まずは、言語の設定です。ここら辺は今までと変わりません。
    win10_03

    今すぐインストールします。
    win10_04

    セットアップを始めています。
    win10_05

    ライセンス条項に同意しましょう。
    win10_06

    新規インストールなので、「カスタム」を選択します。
    win10_07

    インストール先ドライブを選択します。
    win10_08

    インストールが始まりました。15分程度で終わったと思います。
    win10_09

    とりあえずは、簡単設定で進めてしまいましょう。
    win10_11

    ユーザ名・パスワードを設定します。パスワードと同じ文言はヒントには使えません。
    win10_12

    セットアップ中・・・・・
    win10_13 win10_14 win10_15

    インストールが完了しました。
    win10_17

    VMware Toolsもインストールしておきましょう。エクスプローラがさらにフラットなデザインになった気がします。
    win10_18 win10_19 win10_20

    VMware Toolsのインストールには再起動が必要です。
    win10_21

    再起動が終わりました。これが起動時の画面のようです。
    win10_22

    ログイン画面です。
    win10_23

    これで、インストール完了です。ちゃんとスタートメニューも復活しています。Windows 8のスタート画面を持ってきた感じですね。win10_25

     

    タグ:

    SSOサーバをバックアップすることでVMware vSphereを堅固にできるか?

    SSO:
    SSO( Single Sign-on )は基本的にはネイティブLDAPを含む、Microsoft Active Directory(AD)に追加されたいくつかの認証ソースと連携するメカニズムです。SSOはLDAPやAD等の認証システムとvSphereインフラ間のゲートキーパとして役割を果たします。ユーザか管理者が認証ソースに対して認証を確立した時にSSOはユーザに対して使用トークンを与えます。各トークンの使用は一ずつシームレスにトークンのtime-to-live (TTL)を削減します。TTLが「0」に到達した時に、期限切れとなり、バックグラウンドの認証ソースに対して再認証が必要になります。

    単純なインストールで一からvSphere vCenterインフラをインストールする時にSSOはプライム・モード・コンフィグレーションでインストールされます。このモードでインストールを行った場合には認証はローカル・インフラのみに提供されます。vSphere 5.5からSSOは最大10,000ゲストと1、000ホストをサポートします。問題はSSOを失うことは誰もvSphereインフラにログインできないことです。ユーザはローカルな認証でホストに直接認証することはできます。

    これは小規模なインフラでは構わないことです。SSOの紛失はvCenter Serverの紛失同様に痛みを伴います。単純なインストールであれば同じゲストを設定できます。大規模であればvCenter Server と SSO は別ゲストを推奨されています。vSphere 6.0ではSSOはPlatform Services Controllerの一部で、別サーバに置かれます。SSOをゲストにすることでロードバランシングを使用しての単一点障害の排除などの多くのオプションに道が開かれます。

    機能停止からの回避は:
    簡単な方法としてプライマリなSSOフェイルの事故でSSO業務を引き継ぐHAバックアップ・ノードの設定です。これは追加のコストが必要となります。VMwareはApachとの基本的なロードバランシングSSOサーバ・グループの作成を実演説明しています。ロードバランシングSSOサーバ・インフラの設定はより深い認証とロードバランシングの知識を要求されます。

    仮想インフラを使用している場合はSSOサーバが稼働するホスト・フェイルはHAを使用して通常にリスタートするか、バックアップ・ノードが引き継ぎます。もちろんこれは構成エラーを除外しません。このシナリオではスナップショットは非常に有益で、容易にロールバックすることができます。それは構成エラーによる一時的なSSO損失であってもです。この作業に価値があるかどうかはユーザが決めることですが、規模の大きなユーザでは、このような設定をあまり採用していません。

    複数のサイトで稼働させる場合は手法が変わってきます。複数サイトでのインストールにはSSOインストレーション・ドロップ-ダウンからの複数サイト選択が含まれます。複数サイト・選択は複数マスター設定で各サイトで個別のプライマリ・ノードを持つ設定です。違いはユーザが複数サイト・モード設定時にそれらをリンクする一つのSSOサーバを持つことです。

    この設定の潜在的な問題はデータベースがそれぞれの間でレプリケーションをしないことです。これは実質的には問題にはならないでしょう。データベースは時々はレプリケーションが必要ですが、OpenLDAP や AD等の認証システムを別途に使用している間はこの必要性は最低限です。

    ソース:SearchVMware

    タグ: ,

    VMware HAクラスタのホスト障害時の状況を簡単にシミュレーション

    VMware HAクラスタを組んでvSphereホストの障害時にも自動でVMが稼働するホストを切り替えるように設定したとします。そして運用前にテストも慎重に行っていたとします。しかし、実際に問題となってくるとすれば運用を始めてからの環境で本当にVMware HAが機能するかという点です。

    そこでVMwareではVM Resource and Availability Serviceというサイトを用意しています。
    HAsimulator

    このサイトではHAクラスタのESXiホストに障害が発生した際の状況をシミュレートすることができます。
    まずSimulate NowをクリックしEULAに同意します。
    EULA

    VMware KBに従いDRSのDumpを取得しアップロードします。

    DRS Dump

    単一ホストの障害か

    単一ホスト障害

    指定した複数ホストの障害かを設定します。

    複数ホスト障害

    Simulateをクリックしシミュレーションを実施すると結果が表示されます。
    結果

    この結果ではリソースの不足により、2つのVMが再起動に失敗するようです。
    結果2

    このようにシミュレーションやキャパシティプランニングを実施しておくことで万が一に備え、事前に問題を特定し対処することができます。

    より詳細なシミュレーションやキャパシティプランニングを実施したい場合には、是非Veeam ONEをご検討ください。
    製品ページ / 製品ブログ
    Veeam ONE関連記事
    仮想環境へのデプロイを円滑にするVeeam ONE v8のシミュレーション機能
    キャパシティプランニングを助けるVeeam ONEのレポート:ホスト停止をシミュレートして必要リソースを計算するレポート
    仮想環境のムダを見逃さない、Veeam ONEが出力する3つのレポート
    Veeam ONE v8 – さらに強化された仮想環境のモニタリングとデータ保護のアシスト機能

    タグ:

    Linux仮想マシンでVMware Toolsではなくopen-vm-toolsを使う

    VMware vSphere環境では通常、利便性の向上のために仮想マシンにVMware Toolsを導入します。
    しかし、最近VMware社からは、ESXiにバンドルされているVMware Toolsではなく、各Linuxディストリビューションからリリースされているopen-vm-toolsの利用が推奨されています。

    “VMware recommends using the Open VM Tools redistributed by the operating system vendors”
    参考訳:「VMwareはOSベンダーより再配布されているOpen VM Toolsの利用を推奨します。」
    ■CentOS 7におけるopen vm toolsのインストールについて(英語ページ)
    http://partnerweb.vmware.com/GOSIG/CentOS_7.html#Tools

    このopen-vm-toolsはVMware Toolsのオープンソース版の実装です。
    VMwareがオープンソースとして公開したVMware Toolsのソースコードが元となっており、VMwareではopen-vm-toolsを完全サポートしていると明言しています。
    ■VMware Toolsオープンソース化のプレスリリース
    https://www.vmware.com/jp/company/news/releases/20070911b

    「OS ベンダやコミュニティによって再配布され、認定された OS 上で利用される open-vm-tools は VMware によって完全にサポートされます。」
    ■open-vm-tools に対する VMware のサポートについて
    http://kb.vmware.com/kb/2074713

    機能面ではOpen VM ToolsはVMware Toolsとほぼ同等のものとなります。
    Open VM Toolsの利用が推奨されている理由ですが、VMware Toolsの導入にあたって、Linuxの場合、gcc/perlといった追加パッケージの導入が必須であったり、OS設定の再構成を行うといった手間がかかり、また運用に容易に影響を及ぼす作業を必要としていました。

    しかし、open-vm-toolsであれば、ディストリビューション公式のパッケージレポジトリでカスタマイズされたパッケージが用意・配布されており、RHEL/CentOSならyum、Ubuntuであればaptで導入できます。

    通常のパッケージと同じように導入できるカスタマイズがされているため、使用しているOSのバージョンとVMware Toolsのバージョンの互換性を気にすることなく、これまで使用していたVMware Toolsの機能の大半が利用可能です。


    centos7-open-vm-tools

    現在、最新のCentOS 7 デスクトップ版では標準でopen-vm-toolsが搭載されています。
    ESXiでCentOS 7の仮想マシンを稼動させると左画像のようにサードパーティ製のものとして表示されます。
    また、最小インストール版でもyum install open-vm-toolsで導入が可能です。

    依存パッケージ:libdnet/libicu


    ubuntu14-open-vm-tools

    また、Ubuntuではデフォルトでは導入されていませんが、特別なパッケージリポジトリを追加せずにapt-get install open-vm-toolsでインストールすることにより、左画像のように表示されます。

    依存パッケージ:libdumbnet1/zerofree


    これはVMware vSphere環境だけでなく、VMware Playerといった環境でも利用可能です。

    その他VMwareサイト上に各種情報が用意されています。こちらもご参照ください。
    ■Ubuntu 14におけるopen vm toolsのインストールについて(英語ページ)
    http://partnerweb.vmware.com/GOSIG/Ubuntu_14_04.html#Tools

    タグ: ,

    VMwareベスト・プラクティスでのよくある失敗

    ●ネットワーク問題の修正

    VMware環境のネットワークでは誤って設定しましそうなことがいくつかあります。それらの誤った設定は可用性の低下とパフォーマンスの低減をもたらします。

    vSwitch:VMware環境でのvSwitchでは違ったネットワークやVLANの設定用が可能なグループ・ポートがあります。VSS(virtual standard switches) を使用している場合に、構成はすべてのホスト別に作成する必要があり、これによりエラーを起こす可能性が高くなります。

    ポート・グループ:最も一般的なエラーの1つはポート・グループを一貫性なくネーミングしたり、クラスタ内のホスト間のポート・グループ・ネームをちょっと間違ってしまうことです。

    VLANタギング:もう1つの一般的な誤りはクラスタ内のホスト上のポート・グループ間でのVLANタギングです。これは問題のあるホストにVMが移動するときに、VMのネットワーク接続が失う問題を引き起こす可能性を生み出します。

    ●アップリンクの確認

    アップリンクはホスト上のvSphereネットワークの重要な部分で、またよく設定を間違える項目です。このでは最も間違えやすい項目をカバーします。

    一貫性のないアップリンク:最初はホストまたはvSwitch毎の不整合なアップリンク数です。あるホストでは他よりもアップリンクが少ない場合、可用性とパフォーマンスに影響します。

    スピードとデュプレックス設定:2番目の一般的な問題はアップインクが不適切にコンフィグレーションされたスピードとデュプレックス設定です。ユーザはスイッチ・プロバイダからの推奨やネットワーク・チームが設定した基準を理解し、アップリンクがそれらに適合することを確認します。クラスタ内のホストが自動構成されたアップリンクがあったり、他が静的に設定されていたり場合があります。これらがマッチしなければホスト間でのパフォーマンスは一貫性を持ちません。

    ●ストレージ問題の解決

    ネットワークと同様に、ストレージ設定でも間違った設定がユーザのvSphereインストールに悪影響を与えます。ストレージ・レイアーは重要な部分で、間違った設定は低可用性とパフォーマンスを生じます。

    ストレージ・パスの適切な値:ストレージ・デバイスへのパスは非常に重要です。ユーザが必要な冗長性レベルに保てるようにパスを設定する必要があります。ストレージ・パスの一般的な値はユーザ環境でのすべてのvSphere用に設定すべきです。もし違ったパス設定を使用する必要がある場合は同様にクラスタ内でホストを設定る必要があります。

    ストレージ・マルチパス・ポリシー:ストレージ・マルチパス・ポリシーはストレージ・パス同様に重要です。デフォルトではvSphereはユーザのストレージ・アレー用のデフォルト・パス・ポリシーを適応がベストです。VMwareはvShpereに多くの有効なポリシーを組み込んでいて、大手のストレージ・ベンダー用にデフォルトの要求ルールがあります。

    インストールから本番へ移行する前に使用するストレージ・ベンダに適切なマルチパス・ポリシーが設定されているかを確認します。ベンダーのいくつかはマルチパス・ポリシーをサポートしていて、オプションを検討して、最適な可用性とパフォーマンス・オプションを提供するオプションを選択します。適切なパス・ポリシーの構成を行うことで、停止からもたらされるファイルオーバを適切なに終わらせることができます。

    データ・ストア・プレゼンテーション:最後のストレージ項目はユーザのホストに対するデータ・ストア・プレゼンテーションです。vSphereクラスタ内ですべてのホストが同じデータ・ストアのセットにアクセスできるということは重要なことです。これにより適切なHAファイルオーバとvMotionオプションが可能になります。

    多くのユーザがクラスターのホストが1つ以上のデータ・ストアにアクセスできないような設定をしていることがあります。これは故障時にクラスタがすべてのVM(仮想マシン)をリストアできないという結果をもたらします。またクラスタを適切にバランスするというDRSを制限し、VMをホストへマニュアルで移動させる機能をも制限してしまいます。

    ソース:searchvmware.techtarget.com

    タグ:

    VMware/Hyper-Vの仮想ディスクを相互変換可能なフリーソフト【StarWind V2V Converter】

    StarWind V2V ConverterはStarWind Softwareから提供されているVMware/Hyper-V環境に対応した無料のV2V変換ツールです。VMDKファイルからVHDファイルへの変換や、VHDファイルからVMDKファイルへの変換、さらにStarWindのネイティブフォーマットであるIMGファイルも同様に相互変換することができます。

    このツールはVMware社のVMDKフォーマットからマイクロソフトのVHDフォーマットに仮想ハードドライブイメージを変換する非常にシンプルですが便利なファイル変換ツールです。変換元の仮想ディスクイメージへは変更を加えません。

    ソフトを起動するとウィザード画面が立ち上がり、変換元の対象ファイル、変換後のファイル形式(このときディスクタイプも可変/固定から選択)、ファイルの保存先を選択するだけの簡単なステップで操作可能です。

    下記サイトから製品のダウンロードページへリンク可能です。
    ■k本的に無料ソフト・フリーソフト
    ■窓の杜

    V2V_1

    V2V_2

    タグ: ,

    「仮想マシンのディスク統合が必要です。」警告の原因は「孤立したスナップショット」

    VMwareの仮想マシンのアイコンに、黄色い三角のビックリマークがつくことがあります。これはワーニングを示しています。

    001_small

    その仮想マシンを選択して「サマリ」を見た際に、「仮想マシンのディスク統合が必要です。」という構成の問題が表示されている場合は、過去のスナップショットが正しく削除されずに残ってしまった結果、スナップショットのディスクが問題を起こしている可能性が高いです。

    この正しく削除されなかったスナップショットは俗に「孤立したスナップショット(Orphaned snapshot)」と呼ばれます。
    これはスナップショットマネージャに表示されないのにもかかわらず、実際のファイルは削除されていないスナップショットのことです。

    ほかの箇所にも異変の兆候が現れています。

      • 「タスクおよびイベント」のイベントから過去のイベントを見るとスナップショット削除時のディスク統合に失敗した、というログが現れています。

    002

      • 「データストアブラウザ」から当該仮想マシンフォルダの中身を見ると、スナップショット特有のvmdkファイル「xxxxx-000002.vmdk」といったファイルが残存しています。

    003-2

      • 「プロビジョニングされたストレージ」などの値が、仮想マシンに割り当てている仮想ディスクサイズよりも、残存しているスナップショットのファイルサイズ分大きくなっています。

    004-2

    この問題は、スナップショットの統合を実施することで解消します。たとえスナップショットマネージャにスナップショットがなくとも、この統合機能は有効に機能します。

    consolidate_snapshot-2

    統合が成功すればデータストアから孤立したスナップショットのファイルが消え、プロビジョニングされたストレージなどの値が正常に戻ります。

    006

    005-2


    仮想環境モニタリングツールVeeam ONEの最新のバージョン8では、こういった孤立したスナップショットを検知できるレポート機能を備えています。
    Veeam ONE Reporterの標準搭載レポートの1つとして、Orphaned VM Snapshotsレポートがあります。このレポートは孤立したスナップショットの検知に特化したレポートで、孤立したスナップショットにより浪費しているデータストアのサイズや、どの仮想マシン・データストアに孤立したスナップショットのファイルが存在しているかを一覧で表示可能です。

    orphaned_vm_snapshot_combined

    このほか、Veeam ONEバージョン8ではインフラストラクチャリソース監視機能のさらなる強化、姉妹製品のVeeam Backup & Replicationとの連携強化など、さまざまな新機能が追加されています。
    Veeam ONE v8 – さらに強化された仮想環境のモニタリングとデータ保護のアシスト機能

    ぜひ評価版をダウンロードし、強力な監視機能を体感してください。

    タグ: , ,

    CentOSをVMware環境上で便利に展開・運用する方法

    RHEL系のメジャーなディストリビューションであるCentOSは、Debian系のUbuntuと並び、よく紹介されているLinuxです。業務環境で運用されている方もいれば、個人で触れている方もたくさんいます。
    スーパーコンピューターにも搭載されているCentOSですが、仮想マシン上にも多くのCentOSマシンが展開されています。多くの場合、最小構成でのインストールが行われています。
    ですが、VMware環境上で、最小構成でインストールしたCentOSを展開・運用するには少々注意しなければならない点があります。
    本記事では仮想環境特有の注意するべき点を紹介いたします。

    【環境】
    インストールに使用するISO:CentOS 6.5のminimal.isoを想定します。
    インストール先仮想環境:VMware PlayerまたはESXi、およびその双方
    また、インストール時はデフォルトの設定を選択します。

    ※便宜的にrootアカウントを利用して進めています。セキュリティポリシーに合わせて適切なアカウントを用意し実行しましょう。

    ■1:[VMware Player限定]簡易インストールを使わない

    VMware Playerで仮想マシン作成時に、「インストール元」にISOファイルを選択すると「簡易インストール」というオプションがあります。

    easy_install

    このオプションは自動的にインストールを進めてくれる便利な機能ですが、この機能をMinimal CentOSで使うと戸惑う事態が発生します。
    そのまま簡易インストールを進めると、以下の画面で停止してしまい、強制終了させるしかなくなります。
    強制終了させた場合、仮想マシンデータが破損して起動しなくなることがあります。(実際にありました。)

    easy_install_13

    再起動が正常に行われない原因ですが、スクリーンショット内の最後の行を見ると、「eject: command not found」と出力されています。
    これは最後にインストールされるVMware Toolsの導入後に、仮想ディスクドライブ内にあるISOファイルをイジェクトしようとしていますが、Minimal CentOSではイジェクトを行うパッケージejectがデフォルトではインストールされません。
    ejectがないので当然イジェクトは行われずその後の操作に移れず停止してしまいます。

    インストール画面を覚えることも重要ですので、「後でOSをインストール」を選択しましょう。インストール画面は日本語のGUIで進められますので、苦労することなくインストールが可能です。

    ■2:VMware Toolsのインストールがそのままではできない

    VMware環境に仮想マシンを展開した場合、VMware Toolsを導入することが大半だと思います。
    VMware Player環境ではホスト・ゲスト間のフォルダ共有、ESXi環境では時刻同期、VMware Power CLIを使ったコーディングも可能です。
    弊社が取り扱う仮想環境特化のバックアップツールVeeam Backup & Replicationも、OS問わずVMware Toolsのインストールを推奨しています。

    しかし最小インストールのCentOSにはVMware Toolsは入りません。パッケージに不足があるためです。

    non-perl_bad_interpreter

    以下のパッケージを導入する必要があります。

    eject – 手動でOSインストールしたからといって不要ではありません。VMware Toolsのインストールも仮想CDドライブに専用のISOがマウントされ、インストールの一番最後にejectコマンドを打ちます。
    VMware Toolsのアップグレードのたびに引っかかるのは大変面倒です。すぐにインストールしましょう。

    gcc – GNUコンパイラコレクション。VMware ToolsのプログラムはC++で書かれているため、コンパイラが必要です。gccをインストールしましょう。

    perl – Linuxでは定番のスクリプト言語ですが、Minimal CentOSにはありません。そしてVMware Toolsのインストーラーはperlスクリプトです。これがないとインストールできません。

    この3点さえあればVMware Toolsはインストールすることが可能です。yumを使い導入してしまいましょう。

    ■3:[ESXi限定]ネットワーク設定を調整せずにテンプレート化およびクローンしてはいけない

    作成した仮想マシンは、環境の大規模展開を想定している場合や、再度のインストールが面倒な場合に、必要に応じてテンプレート化されます。
    しかし、この際、作成したMinimal CentOS仮想マシンをそのままテンプレート化しないでください。

    そのままではLinuxのデバイス管理を司るudevがethXごとにMACアドレスを記録してしまっています。
    そのため、テンプレートからの展開で新しい仮想NIC(=新しいMACアドレス)割り当てが行われた際にeth0と別のネットワークアダプタeth1として認識されてしまい、既存のネットワークアダプタeth0が起動せず、ネットワーク接続がうまくいきません。
    一方、フルインストール版(デスクトップ環境を含む)ではネットワーク接続ができているように見えます。

    これはフルインストール版ではネットワーク設定に関してはNetworkManagerが管理しており、新しいNICに対しても従来のネットワーク設定が利用されているためです。
    ifconfig -aで確認すると、eth0ではなく新しいeth1がネットワークに接続できていることが表示されます。

    ifconfig-a_restored_centos_desktop

    一方、Minimal CentOS仮想マシンでは、NetworkManagerがインストールされず、従来からのNetwork Administration Tool(NAT)が使われます。これはNetworkManagerのようなネットワーク設定の転用をしないため、ネットワーク接続ができなくなります。

    ifconfig-a_restored_centos

    このイーサネット接続の問題に対する解決策は2つあります。

    ●1:/etc/udev/rules.d/70-persistent-net.rulesを編集する。
    これは、ネットワークインターフェースの関連付けをMACアドレスではなく、PCIアドレス(PCI ID)に結びつけることにより自動再設定を回避するという方法になります。
    VMwareのVMXNET3環境であれば、PCIアドレスはすべてVMwareのものとなっています。
    E1000環境であれば、ESXiホストにささっているNICの製造元のものとなっています。
    ※以下ではVMXNET3環境の場合を案内します。E1000環境では適宜読み替えて設定を行ってください。

    以下、手順を案内します。
    まず/etc/sysconfig/network-scripts/ifcfg-eth0を編集してHWADDRの設定行を削除します。
    このファイルがない、またはHWADDRがもともとない場合は編集する必要はありません。

    PCIアドレスはlspciコマンドで確認可能ですが、Minimal CentOSにはこのコマンドを含むpciutilsパッケージがインストールされていないので、インストールします。
    lspci | grep VMXNET3で結果がアダプターに応じて表示されます。

    lspci-grep-vmxnet3_on_centos


    03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

    行の先頭(下線部)がPCIアドレスです。これをメモします。これを元に以下の手順に従いに70-persistent-net.rulesを書き換えます。
    (事前にコピーしてバックアップを取得してください。)

    • DRIVERS項目の値をvmxnet3(小文字必須)に書き換え
    • ATTR{address}の項目をすべて削除
    • BUS項目を追加し、値にpci(小文字必須)を設定
    • ID項目を追加し、値に「0000:」+lspciの結果(上記の下線部)を設定します。

    etc-udev-rules.d_on_minimal_centos2


    ※画像黄枠
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:a4:2f:b4", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

    ※画像赤枠
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="vmxnet3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0", BUS=="pci", ID=="0000:03:00.0"

    この状態で再起動し、正常にeth0が認識されているのを確認した後、テンプレートを作成すれば問題ありません。

    ●2:/lib/udev/rules.d/75-persistent-net-generator.rulesを編集する。
    もう1つの方法は上記/etc/udev/rules.d/70-persistent-net.rulesを生成するための設定ファイル/lib/udev/rules.d/75-persistent-net-generator.rulesを編集することです。
    etc内のネットワークアダプタ設定情報は、lib内のジェネレータルールに基づき記録されています。
    ジェネレータルールを編集し、VMware環境上でテンプレートからの展開・クローンを行っても設定情報を生成しないようにします。

    以下、手順を案内します。
    まず/etc/sysconfig/network-scripts/ifcfg-eth0を編集してHWADDRの設定行を削除します。
    このファイルがない、またはHWADDRがもともとない場合は編集する必要はありません。

    続いて現在の設定情報を持っているファイル/etc/udev/rules.d/70-persistent-net.rulesを削除します。
    次に/lib/udev/rules.d/75-persistent-net-generator.rulesを開きます。
    このうち、# ignore Xen virtual interfacesの行を探し、その上に以下の2行を追記してください。

    # ignore VMWare virtual interfaces
    ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"

    lib-udev-rules.d_on_restored_centos

    これで、新しい仮想ネットワークアダプタが接続されてもMACアドレスの固定が発生しなくなります。(70-persistent-net.rulesが作成されなくなります。)

    Ubuntu仮想マシンでは、Minimal CentOS仮想マシンで起きる、udev由来のネットワーク問題は発生しません。
    なぜなら、生成ルール内に、VMwareやHyper-Vといった仮想環境上ではインターフェースとMACアドレスの関連付けを行わないように、例外が設定されているためです。
    上記CentOSの設定方法はこの設定に基づき案内しております。

    lib-udev-rules.d_on_ubuntu_2

    タグ: , ,

    VMware + Net App(Data ONTAP Simulator)を仮想マシンとして導入

    VMwareのストレージとして、多くの方がNet Appストレージを利用されているかと思います。

    運用コストのみならず、この組み合わせの特徴である重複排除機能を活かすことで、
    ストレージ拡張のコストまでも削減することが可能です。
    またVMwareからNFS Datastoreとして、簡単にストレージの管理をすることができます。

    また、Net APP製品の一つである「Data Ontap」は
    仮想マシンとしてNet AppストレージOSを立ち上げることが出来ます。

    今回は弊社環境に「Data ONTAP Simulator ver8.2.1 7-mode」を
    VMware上に仮想マシンとして導入し、Snap Vault, Snap Mirrorの実施を行ってみました。

    Ontap1

    これは、Net Appサポートサイトからダウンロードでき、
    簡単にData ONTAPのほとんどの機能を体験することが出来るのが魅力です。
    解凍しフォルダをvSphereにアップロード後、仮想マシンとしてデブロイします。

    ただ、その前の留意点として、
    Data ONTAP Simulatorはsparceディスクで構成されているので
    vSphere5.x以降では起動できません。

    回避策としてsparceディスクを通常のディスク形式に変換する必要があります。
    ■VMware KB
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080408

    起動後はディスクの初期化を行い、NFSデータストアとしてマウントすることができます。
    Snap vault機能を利用するには、下記の設定をします。

    ■Snap Vault構築
    1.ソースボリュームを作成
    2.Snap Vault機能をオンにする
    options snapvault.enable on
    3.でターゲットホストを指定
    options snapvault.access host=<ホスト名 or IP>
    4.同様にターゲット側でもボリューム作成、ソースホスト設定
    5.スナップボルト実行(セカンダリのみで実行可)
    snapvault start -S <ソースホスト名>:<ソースボリューム名> <セカンダリボリューム名>

    ONTAP4

    ■Snap Mirror構築
    1.ソースボリュームを作成
    2.Snap Vault機能をオンにする
    options snapmirror.enable on
    3.ターゲットホストを指定
    options snapmirror.access host=<ホスト名 or IP>
    4.同様にターゲット側でもボリューム作成、ソースホスト設定
    5.セカンダリのボリュームをリストリクトモードにする
    vol restrict <ボリューム名>
    6.スナップミラー実行
    snapmirror initialize -S <ソースホスト名>:<ソースボリューム名> <セカンダリホスト名>:<セカンダリボリューム名>

    ONTAP3

    さらに「7-mode」以外に、「Data ONTAP Simulator Cluster」というクラスター内に
    同居できるものがあります。基本的なセットアップ方法も同一です。
    これからのストレージ性能の向上とNet Appの動向に注目です。

    Hyper-V:物理マシンをどのように仮想に変換するか – Disk2VHD

    Hyper-V用で物理マシンを仮想に変換するツールで、Disk2VHDというツールがあります。0.9MBで Windows Sysinternalsからダウンロード可能です。

    http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

    利用方法を簡単に説明します。
    Step 1. Windows SysinternalsからDisk2vhdをダウンロードします。

    Disk2vhd1
    図1:

    Step 2. 変換したい物理サーバ上でDisk2vhdを起動させさせます。
    vhdxディスクを作成するために「use vhdx」をクリックします。必要に応じて「use VSS」を選択します。vhdxディスク用のロケーションを選択します。

    Run-Disk2vhd2
    図2:

    Step 3. vhdxフォーマットへディスクを変換し、Hyper-Vホストへコピーします。

    Disk2VHD3
    図3:

    この処理後にHyper-Vサーバへコピーしたvhdxファイル/ディスクになります。

    Disk2VHD4
    図4:

    Step 4. 作成したディスクを使用するためにはVMを最初に作成します。Hyper-V Managerで「New – Virtual Machine」を起動させ、コンフィグレーションを行います。

    Disk2VHD6
    図5:

    Step 5. 「Connect Virtual Hard Disk」ステップで、残りのステップを終了させます。

    Disk2VHD6
    図6:

    Step 6. VMを右クリックし、「Run」を選択して、再度右クリックし、それに接続します。

    Disk2VHD7
    図7:

    ハードウェア・コンフィグレーションは複雑なためVMを起動させるまでに時間がかかります。

    Disk2VHD8
    図8:

    タグ: ,