こちらのKBにある推奨構成パターンのうち、2番目のPSC外だしのvCenter x2台構成を管理しているのだが、時刻同期やメンテ対応などで色々と面倒。今後はHA化もできるし、PSC内蔵パターンでシンプルに構成するのがいいとは思うのだが、その場合はMulti vCenter構成にすることに制約が出てくるのが悩ましい。vCenter内蔵のPSCを他のvCenterから使ったり、PSC内蔵のvCenter同士を同期する構成は非サポートになると書かれているし、どうしたものかね。
動作確認のためにMulti vCenter構成にしているだけなんだけど。
VCSAのShellモード(Appliance Shell/Bash Shell)
自分で設定しておいて忘れていたのだけれども、vCenter Server Applianceは普通以下のAppliance Shellがデフォルトになっている。
この場合、Bash Shellに移行するには KB2100508 にあるとおり、shell.set --inabled true したうえで shell すればよい。
Using username "root". VMware vCenter Server Appliance 6.0.0.20000 Type: vCenter Server with an external Platform Services Controller Last login: Tue Nov 22 01:11:50 2016 from 172.16.254.1 Connected to service * List APIs: "help api list" * List Plugins: "help pi list" * Enable BASH access: "shell.set --enabled True" * Launch BASH: "shell" Command>
でも、私の環境では自分で昔設定したんだろうけど、Bash Shellが最初に表示されるようになっていた。上記KBにもあるけれど、おそらく chsh -s /bin/bash root してデフォルトをBashに変更していたっぽい。
この状態からデフォルトのAppliance Shellに戻すには、まぁKBにあるとおり chsh -s /bin/appliancesh root して一旦Shellをログアウトすればよい。
ただの備忘録。
VSAN6.2へのアップグレードがオブジェクトアクセスエラーで出来ない場合の対処方法
VSANのディスクフォーマットをアップグレードしようとしたらこんなエラーががががが。
ちょいと調べたら、このオブジェクトへのアクセス権ステータスをどうにかしないとアップグレードできないということなので、対処。
対処にはRVCが必要。ま、vCenter Server Appliance (VCSA)に入っているので、それを使うのが一番手っ取り早いかと。
VCSAにログインして、Bash Shellに一旦入ってから、rvc account@localhost でRVCに入れる。デフォルトのadministrator@vsphere.localのままならlocalhostだけでもOK。ローカルの管理者アカウントを変更しているなら、こんな感じで。
あとは、普通にcdコマンドでパスを移動してDC配下のComputersに行くか、さらにその下のクラスタに移動して、vsan.purge_inaccessible_vswp_objects コマンドを実行。Computersにいるならクラスタ名を、クラスタにいるなら . を引数につけて実行。
確認メッセージで Y を押せば、オブジェクトの削除が行われる。ま、本当にそのオブジェクトを消していいかどうかはご自分でご判断を。
とりあえずこれで、この問題は解決。
vCenter Server Appliance 6.0 がディスクのエラー(Bad Block)で正常起動できなくなった際の対処メモ(当然ながら自己責任版)
※本エントリーを参考にして操作を実施した結果、問題が発生しても責任は負いません。自己責任で参考にしてください。本操作を実施することにより、VMwareからの正式なサポートを受けられなくなる可能性があります。
vCenter Server Appliance (VCSA) はファイルシステムとしてLVMで構成されているが、突然の電源断やディスク容量の枯渇などによってファイルシステムに破損などが生じた場合に、正常に起動できなくなることがあります。
その場合は、fsckをするしかないのですが、デフォルトではroot権限がDisableとなっていてbashが起動できないため、ちょっと対処が必要となります。
VCSAは複数の仮想ディスクで構成されています。特定のディスクがrwでマウントできないなどの状況となった場合には、roマウントした上で機能が制限されたコマンドプロンプト状態となります。
しかもこの場合にはrootアカウントでログインした上で、"shell.set --enabled True"コマンドでShellを有効化してShellコマンドでShellに入れとメッセージが出るのですが、そもそもshell.setコマンドが"unknown command"として受け入れてくれない場合があります。というか、これが使える状況なら以下の操作は不要です。
この場合はもはやどうにかしてbashにたどり着かないとfsckもなにもないので、以下の手順を行います。
1. Ctrl+Dコマンドで再起動し、GRUBのブートローダ画面でスペースキーを押すなどして自動起動を停止する
2. "p"を押してrootのパスワードを入力する
3. "e"を押して起動オプションの編集モードに入る
4. (おそらく2行目にある) "kernel /vmlinuz-3.0.xxxx"で始まる行を選択し、"e"を押す
5. 起動オプションに"init=/bin/bash"を追記する
6. Enterキーを押してGRUBのメニュー画面に戻る
7. "b"を押して起動する
8. Bashで起動するので、まずはroでマウントしてしまっている/dev/sdaXについてfsckを実行する
以下の例では /dev/sda3 にBad Blockが検出されている
9. 再起動する(おそらくCtrl+Dでは正常に再起動できないので、仮想マシンとしてリセットするしかない)→ここで正常にVCSAが起動できた場合は以下の手順は不要。念のためもう一度F12&F11キーで正常操作としての再起動を行って問題ないことを確認する ※ここで再起動をしておかないと、PSCとの間で正常に連携できない状態となっている可能性があります
10. LVMの / (root)がマウントできない状態となっていて再度vCenterが起動しない場合は、改めてCtrl+Dで再起動した上で、1.〜7.までの手順を再度実施する
11. Bash画面で"chsh -s /bin/bash root"を実行し、Shellの変更が設定されたことを確認のうえでVCSAを再起動する(仮想マシンとしてのリセット)
12. rootパスワードを入力してログインすると、ファイルシステムのリカバリが可能なコマンドプロンプト状態(repair filesystem)#で起動するので、"fsck /dev/mapper/log_vg-log"コマンドでチェックを実施する
13. Ctrl+Dコマンドで再起動する
14. めでたく正常にVCSAが起動することを確認する
なお、本手順を踏んでVCSAとしては正常に起動したとしても、vCenterとしての正常動作ができるかどうかまではわかりません。DBレベルで修復不可能な状態になっていた場合は、残念ながらサービスとしては回復できない可能性があります。
また、PSCを分離している場合は、PSCの復旧後にしばらく(10分程度でいいかと思いますが…)時間をあけてからVCSAを起動してください。
VIX APIってご存知ですか？ - vExpert Advent Calendar
vExpert Advent Calendar 12/5 エントリーです。
VMwareの仮想マシンを実行する製品には、共通してVIX APIというAPIが用意されています。公式のVMwareウェブサイトではこちら。
https://www.vmware.com/support/developer/vix-api/
このAPIは、vSphere ESXiはもちろん、WorkstationやPlayer、そしてFusionでも使用することができる共通のものとなっています。
…で、このAPIを使うと何ができるかといいますと、VMware Toolsがインストールされて動作しているゲストOSに対して、ネットワークを通すことなく様々な制御をすることができます。いわば公式なバックドア(^_^;)として使用することができる…とまで言うといいすぎですが、まぁ悪いこともできなくはないですね。
Workstation環境だと、こんな感じの仕組みとなります。
この機能はデフォルトが有効です。無効にしたい場合は、vmxファイルに以下の指定します。ESXiホストの場合は、/etc/vmware/config で指定することによってホスト全体で無効化することも可能です。
guest.commands.enabled = "FALSE"
この情報に関するVMwareのKBはこちら。
http://kb.vmware.com/kb/1010103
その他、VIX APIはセキュリティリスクになり得ますので、気になるという方は以下の情報を一読されることをオススメします。
https://www.vmware.com/support/developer/vix-api/vix115_reference/security.html
上記公式サイトにサンプルのコードもあります。以下のリファレンスページに、設定方法や使い方なども載っています。CやPerl、C#などに対応しています。
https://www.vmware.com/support/developer/vix-api/vix115_reference/
vSphere 5 からは以下のようにVIX APIはvSphere APIの一部となっています。そのため、vCenterサーバを通じてゲストOSに対して処理を投げることができるようになっています。
そんなわけで、ためしにLinux環境からvCenterを通じてESXiホストで実行される仮想マシン上で動作するゲストOSに対してVIX APIを通じてコマンドを実行してみるサンプルプログラムを作ってみました。
[root@localhost tmp]# ./vixtestcommand http://(vCenter IP Address)/sdk (vCenter Account) (vCenter Password) "[(Datastore)](VM Folder)/(VM Name).vmx" (Guest OS Account) (Guest OS Password) (Script) DEBUG: Success jobHandle 34603071 DEBUG: Success hostHandle 34603070 DEBUG: Before Opening VM DEBUG: Opening VM.... DEBUG: Opened the VM DEBUG: waiting for tools DEBUG: tools up DEBUG: logged in to guest DEBUG: about to execute remote command DEBUG: about to execute remote command (Script) DEBUG: with args Script execution status is 0 Script command exitCode is 0 DEBUG: execution completed....
おー、ちゃんとvCenterを通じて、仮想マシンが実行されているホストに接続し、仮想マシンに接続し、VMware Toolsを通じてゲストOSに接続し、コマンド実行されました。こんな感じで、ゲストOSがネットワークにつながっていなくても、vCenterサーバの管理者アカウントとパスワード、そしてゲストOSのアカウントとパスワードさえわかっていれば、ゲストOSに対する処理を実行できます。管理環境からネットワーク的な接続性のないゲストOS環境に対して処理を実行することができますので、上手く使えば仮想マシン展開後の管理に便利に使えそうです。
ただ、ゴメンナサイ、このサンプルプログラムには一部オープンになっていないコードを含む可能性がある拾い物を8割ぐらい使ってささっと作ってしまったため、コードの公開は残念ながらできません…。ただ、上記のサンプルコードとリファレンスの情報があれば、同じようなプログラムを作ることはそんなに大変ではないのではないかと思います。
Happy Cording!!
え、プログラミングとか面倒？そんな方にはCisco UCS Director(^_^;)。VIX API機能を簡単に使えるワークフローを書くことができる機能が標準で実装されています。すぐにVIX APIを活用できますよ!!
http://www.cisco.com/c/dam/en/us/td/docs/unified_computing/ucs/ucs-director/vix-script/VIXScriptUseCaseGuide.pdf
Enjoy Happy Life!!
ACI本刊行記念!! ACIとNSX - vExpert Advent Calendar
vExpert Advent Calendar 12/4 エントリーです。
本日、皆さま待望の『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』がついに発売されました!!
Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー
- 作者: Lucien Avramov,Maurizio Portolani,株式会社クイープ,水島勇人
- 出版社/メーカー: インプレス
- 発売日: 2015/12/04
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
なお、本書の著者の一人 Lucien Avramov は大の日本好きでこれまでも何度も日本に訪問しております。まだ未定ですが、年明け2/24の開催を予定している ACI友の会#3 にもしかしたら…。乞うご期待。なお、Twitterでもつぶやきましたが、何らかのかたちで私とつながっている方で、本書を買ったという方には、ご希望であれば英語版の本書を差し上げます(私の手元に在庫がある限り…)。ACIの理解を深めるついでに英語の勉強にいかがですか？(^_^;) 何らかの方法でご連絡ください。
…と宣伝っぽい内容はそれくらいにして…vExpert Advent Calendarでこのネタはどうなんだってご意見もおありでしょうが…どなたか譲るよ！って書いたのに誰も手を上げないんだから仕方がない！縛りなしってルールだし！そして別に何かをディスるつもりもないし(^_^;)！！
そんなわけで、本エントリーでは『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』日本語版の出版を記念して？、いいとか悪いとかではない視点のCisco ACI (Application Centric Infrastructure) /VMware NSX論を少し書いてみたいと思います。お約束としては、あくまでも個人の意見、個人の視点です。会社の人間として喋るときにはちょっと別の言い方をしているかもしれません(^_^;)。また、あまりテクニカルに深くは踏み込みません。
本書『Cisco ACI ポリシーベースのデータセンター アーキテクチャ/コンセプト/メソドロジー』の英語版はほぼ1年前に出版されたものですので、ACIの情報としては残念ながらすでに最新の内容ではありません。原著が出版された時点ではまだ対応していなかった機能や構成が可能になっている部分もすでに沢山あります。今月リリース予定の新バージョンでも、すでにこちらのオフィシャルブログなどでも触れられている通り、かなり楽しみな機能が数多く追加・拡張されていく予定です。ACIは新しい製品ですので、まだまだ積極的に様々な機能が追加・拡張されているフェーズにありますが、そうした新機能の学習という目的には本書はあまり適していないかもしれません。しかしタイトルの通り、本書は主にはアーキテクチャ、コンセプト、メソドロジーなどといった、バージョンがあがったり機能が拡張されていったとしても陳腐化することのないそもそもの部分、つまりはACIの根本的な思想・考え方といった内容に比較的比重が多く割かれていますので、ACIを表面的な部分だけでなくしっかりと「どういう考え方に基づいてACIはデザインされているのか」といった基礎的な部分から理解されたい方にとっては、今読んでも十分にお役に立てる内容が詰まっているのではないかと思っています。
さて、本エントリーではACIそのものについてはあまり書くつもりはありません。そのあたりはぜひ本書をお読みください(しつこい？といっても、本書が売れても別に私には1円も入ってきませんけど)。このエントリーで書きたいテーマは「手段としてのネットワークを活用するために」といったようなふわっとした感じの内容です。
OpenStackやDocker、そしてもちろんSDNなど、最近はコンピューティングの側面から見てもネットワーキングの側面から見てもITインフラストラクチャに求められることが大きく変化しつつあります。トレンドや技術動向をしっかりと把握しておくことは大切ですが、そうした情報に流されて「わが社もクラウドだ！」「SDNを導入しよう！」などとそれ自体を目的化させてしまわずに、ぜひ自社のIT基盤に求められているもの、ひいてはビジネスを支える要素として求められているものは何なのか、といった目的をしっかり踏まえたうえで、手段としてこれらの新しい流れを活用することができるのかどうか、冷静に検討頂ければと思います。
この流れを生み出したきっかけはやはりサーバ仮想化技術にあるでしょう。2000年代中ごろから現在にかけてのVMwareの飛躍はまさにそれを体現したものといえます。サーバ仮想化はITインフラリソースをソフトウェア的に構成することができる時代への入り口を開いたと言えます。その流れはインターネットの普及と高速化と相まってパブリッククラウドへとつながり、そして現在では雲の向こう側かこちら側かなどといった違いを超えて、どのような形態であろうとも、ITリソースは「必要なときに、必要な対象に対して、必要なリソースを、必要なだけ」提供することを可能とするサービス化された仕組みが求められるようになりつつあります。
サーバの役割を持つコンピュートリソースは物理サーバであろうと仮想マシンであろうと、そして最近ではコンテナであろうとその上で提供されるサービスという視点から見るとどのような形態で仕組みが作られていようと関係ないわけで、ITインフラリソースの要素の中で最も論理化が進みやすい要素でした。そしてまずは「それまで使われていた」タイプの企業が必要としているいわゆるクライアントサーバ型的なエンタープライズアプリケーションであっても問題なく使用できるサーバ仮想化が普及し、そして「これから使われていく」タイプのモジュール同士がAPIやQueueで結び付きながらブラウザやアプリを通じて柔軟にサービスを提供していく新しいカタチのアプリケーションが次第に広まっていく中で、Dockerのようなもはや仮想化ですらないアプリケーション実行環境そのものを展開する仕組みへと発展しつつあります。
このITリソースのサービス化の流れは当然ストレージやネットワークにも波及し、その流れの中でネットワークの範囲としてはCiscoのACIやVMwareのNSXが登場してきたと言えます。
そんなACIは確かにネットワークのソリューションではあるのですが、その根本的な製品思想はこれまでの企業ネットワーク製品とは大きく異なっています。そういう意味では、既存ネットワークの延長線上として「ソフトウェア的に論理的なネットワークを作ることによってネットワークの構成管理運用の柔軟さと展開の速さを高めよう」という、いわゆるSDNという括りにも収まるのだろうか？と思う部分も多くあります。まぁSDNという括り自体も人それぞれなので、括りに収まるもなにもないのかもしれませんが。
また、SDNをどう捉えるのか、という問題でもあるかと思うのですが、SDNをソフトウェア「だけ」で実現する新たなネットワークと考えるのだとしたら、物理的なハードウェアスイッチであるNexus 9000シリーズに依存したソリューションであるACIはそもそもSDNではないということになってしまいます。しかし、SDNをソフトウェア「によって」実現する新たなネットワークと考えるのであれば、ACIの論理的な側面は完全にAPIによって制御が可能なソフトウェアとしての側面を持ちます。ハードウェアによる処理性能・安定性と、ソフトウェアによる論理的なデザインと構成、その両面をACIは併せ持っています。
ACIは単に「これまでのネットワークの要素をソフトウェア化する」(＝ネットワーク仮想化？)ものではありません。ネットワークリソースにサービス化が求められるなら、それはどうあるべきなのか？という根底から検討し、それを実現する手段として最適なかたちを目指して製品化されたソリューションです。そんなわけで、ACIに対しては、わかりづらい／よくわからない、既存のネットワーク管理のノウハウやナレッジが通用しないのではないか、アプリケーション視点のポリシー管理？これまでとまったく違う管理手法を取り入れるのには抵抗がある、など等のご意見が多数あることは事実かと思っていますし、そうであるからこそ、ACIのアーキテクチャ、コンセプト、メソドロジーといった部分をご理解いただくために本書のようなものが必要だと思っています。
会社としても、そして世の中としても、CiscoのACIとVMwareのNSXは競合であるとして色々なところで扱われています。確かに「新しいネットワークのカタチ」としてお客様がいわゆるSDNを検討された際に土俵に上げられるソリューション同士であるという意味では、競合といえる部分はあるかと思います。しかし、両者を見ているとおそらく次第にこの2つのソリューションは別のものであるという認識が少しずつ理解されていくのではないかとも思っています。
NSXの強みの1つは、やはりvSphere環境との高い密結合にあると思います。vSphere環境を前提としたNSX-vとNiciraの流れを持つNSX-MHがありますが、おそらく前者が次第に拡大していく方向で統合されていくことになるのではないかと思われます(中の人じゃないので知りませんけど)。NSXのコンポーネントには仮想アプライアンスとしていわば仮想マシンの一種として存在している要素(主にNorth-South方向の通信に関わる)と、ESXiのVMkernelの中に組み込まれる要素(主にEast-West方向の通信に関わる)の両方がありますが、NSXの肝はVMkernelに組み込まれて動作する分散仮想ルータや分散仮想ファイアウォールにあると思います。VMkernelに組み込まれるからこそ、vSphere環境の仮想マシンとの親和性が非常に高く、かつ他社にはまねできないソリューションを実現することができているわけです*1。NSXはサーバ仮想化のESX同様にハードウェアとしてのネットワークに依存しない(土管化？)仕組みを実現することを基本思想として持っているので、仮想アプライアンスとKernelモジュールでネットワーク機能を実現する仕組みはそれを体現する実装といえると思います。
逆にACIは、特定のホスト側の仕組みには依存しない、ということを設計思想に持つ疎結合型のソリューションです。特定のHypervisor、特定のOS、物理仮想の違いなどに依存せずに、あらゆるコンピューティングの形態に対して統一されたポリシーを提供することができます。しかし逆にハードウェアとしてのネットワークには強く依存する実装であるため、物理スイッチであるNexus 9000、そして物理アプライアンスとして提供されているAPIC (Application Policy Infrastructure Controller)と、ACIを使用するためには前提としてハードウェアが必要です。ACIを多くの基盤でご利用いただきたいと考えていますが、誰もが必要とするものでもないとも考えています。論理的なネットワークを動的に追加・構成・管理・変更していく、いわばネットワークに柔軟性を求める使い方をしたいという場合にはACIはとても有用ですが、静的に安定して個々のスイッチが自立分散して動作していてシンプルに広帯域・低遅延の拡張性のあるネットワークが欲しいという場合には、ACIではなく、いわゆるイーサネットファブリック的な使い方の方が向いているかもしれません。また、これまでどおりの、各ネットワーク機器を個別に構成し、標準化されたルーティングプロトコルなどによって情報交換は行っても各機器は自立して動作する使われ方は、SDNの登場によって使われなくなるということもないと思います。これらの向き不向きは業種や規模というよりも、ネットワークに求めている「使い方」次第といえるでしょう。
この先しばらくの間はSDNという括りでCiscoのACIとVMwareのNSXについては両者の比較やら競り合いやら色々な情報がニュース記事や両社からの発表などによって出てくることになると思います。しかし、5年後ぐらいにはきっと、ルータとスイッチほどとは行かないまでも、CiscoのスイッチでいえばNexusとCatalystぐらいのカタチで目的や使われ方が違うものとして認知されるようになっているのではないでしょうか。
明日のvExpert Advent Calendarもなぜか私なので、明日はまったく今日とは正反対の感じで短めのエントリーでVMwareがらみの小ねたを紹介したいと思います。
