2016年3月26日土曜日

ESXi6.0 u2にて、アップデート方法とVSANエラー対策

vSphere6 Update 2の発表により、ESXiも6.0 Update2がリリースされました。
ISOからアップデートすることも可能ですが、KVM等が接続されていないデーターセンターなどでは、ISOからのアップデートは面倒かと思います。

メインバージョンのアップデート出ない場合は、ESXiは、vibファイルによるアップデートが可能です。
いわゆるパッチの適用と同じ手法となります。

まずは、パッチの入手先ですが、
https://my.vmware.com/group/vmware/patch#search
から、VIBファイルとして入手が可能です。


ダウンロードしたZIPファイルは、ESXiから参照できるのデーターストアーにアップロードしましょう。


あとは、PowerCLIを使ってアップデートをする方法が一応正規なやり方ですが、それだけのためにPowerCLIをインストールするもの面倒な場合は、ESXiのSSHを有効にすることでパッチ適用が可能です。



SSHサービスの状態を確認します。

必要に応じて、サービスを起動します。


これでSSHで接続できる準備ができました。
早速TeraTermを使って接続をしてみましょう。

接続できると、シェルが表示されます。

早速、アップデートしたファイルを確認してみます。
DataStoreは、「/vmfs/volumes/(DataStore名)」にあります。

cd /vmfs/volumes/(DataStore名)
で、lsコマンドでファイルがあることを確認します。


ではでは、早速アップデートを実行してみましょう。
通常のアップデートは、以下のコマンドで行います。
esxcli software vib update -d アップデートファイルのフルパス
で、OKなのですが、なにやらエラーが表示されました。

 [DependencyError]
VIB VMware_bootbank_esx-base_6.0.0-2.34.3620759 requires vsan >= 6.0.0-2.34, but the requirement cannot be satisfied within the ImageProfile.
VIB VMware_bootbank_esx-base_6.0.0-2.34.3620759 requires vsan << 6.0.0-2.35, but the requirement cannot be satisfied within the ImageProfile.

Please refer to the log file for more details.

調べてみるとKBが出ています。
VMware Virtual SAN (VSAN) VIB dependencies introduced in ESXi 6.0 Update 2 onwards (2144595)

どうやら、プロファイル情報をアップデートしないと駄目なようですね。

ということで、ESXi6.0 Update2を適用するときは、
esxcli software profile update -d /vmfs/volumes/(DataStore名)/update-from-esxi6.0-6.0_update02.zip -p ESXi-6.0.0-20160302001-standard
アップデートはそれなりに時間がかかります。
アップデートが終了したら、とくにSuccessなどのメッセージは出ず、アップデートされた一覧がずらっと表示されます。

これでOKです。
あとは、ESXiを再起動すれば作業は完了です。

ESXiホストの再起動後、vSphere Clientから接続してバージョンを確認しておきましょう。
きちんとビルド番号が上がっていればOKです。







2016年3月19日土曜日

インスタントクローンを使ってみよう その1(概要編)

インスタントクローンという言葉をご存知でしょうか?
インスタントというとラーメンがまずイメージされるかもしれませんが、ほぼ同じイメージをしていただければよいと思います。

通常仮想マシンのクローンを展開する場合、今までは
  • フルクローン
  • リンククローン
の2つがあることはご存知だと思います。

フルクローンは、仮想マシンの情報をすべてコピーすることです。
これだと、完全にコピー元マスターとは別物としてコピーされた仮想マシンが出来上がりますが、マスターの仮想マシンが、2TBなど大容量なVMDKファイルを持っていると、これを複数古コピーをすると時間もかかりますし、容量も大量に消費することになります。



これに対して、リンククローンは、マスターの仮想マシンにてスナップショットをとり、そのスナップショットまでのデーターをクローンされた各仮想マシンで共通のディスクとして参照します。
当然ながら各仮想マシンで、個別設定をするとマスターのディスクと別に差分ディスクが、リンククローンで展開された各仮想マシンに割り当てられます。
これにより、OSやOfficeなどの各仮想マシンで共通な部分は、1つのVMDKを参照し、そこからの差分だけを各仮想マシン個別で保存するため、ディスク容量を削減できることと、クローン作業も大変高速で行うことができます。(ディスクコピーが事実上不要のため)
(リンククローンで構成する場合基本的にスナップショットは、仮想マシンがパワーオフの状態で取得しなければいけない)



個人的には、リンククローンでも十分じゃないかと思うのですが、今動いている仮想マシンのメモリー状態までをスナップショットのようにとってしまい、その仮想マシンのメモリー状態までを含めてクローンをつくるというリンククローンにさらにメモリー状態をコピーした仮想マシンというのが、インスタントクローンとなります。
ちょっとわかりにくいですが、いわば仮想マシン上でWindowsが起動して、そのうえでExcelでなんらかのファイルを開いたままの状態の仮想マシンを瞬時にクローンを作るという方法です。
メモリー状態までをコピーするので、OSを起動するまでの時間すら不要になるため、クローンができた瞬間から仮想マシンにすぐに利用ができるというのが「インスタントクローン」の技術です。


そんなことして大丈夫なのかというのは、さておき、こういった高速なクローニングはどういったところで活用できるでしょうか?

1つは、クラウド上で大量にAPサーバーを展開する場合です。
モバイルゲーム業界など、パブリックにWEBサービスを展開する場合、ユーザーのピークに合わせてAPサーバーを大量に展開するケースがあります。
この場合、クラウドで環境を構築するケースが多いと思いますが、マスターの仮想マシンを大量にコピーして、OSやアプリケーションサーバーを起動してとなると、時間がかかります。

これを、インスタントクローンとDockerを活用し、VMwareの提供する、Dockerのための薄いOSであるPhoton OSを利用することで、APサーバーをコンテナ化したものを瞬時に展開し、展開後すぐにAPサーバーとして利用することができるというメリットがあります。

2つ目は、使い捨て仮想マシンです。
たとえば、KIOSK端末などの公開端末によるインターネット閲覧などです。
公開端末は、ユーザー側の様々な操作でマルウェアの感染やOSの破壊などが行われる可能性があります。この機能を利用すれば、OSの再起動など一切なく、マスターから瞬時にOS起動後のクローンができますので、ユーザー利用後新しいユーザーが利用するたびにマスターイメージの状態(クリーンな環境)を提供できます。
これは、昨今流行りのWeb分離においても同じく可能ではないかと思います。

このインスタントクローン、次期Horizon7 Hybrid Mode(Project Enzo)で利用される機能ですが、このインスタントクローンの機能自体は、vSphere6の機能であり、PowerCLIを利用することで、Horizon7に関係なく利用することができます。

では、次回から実際にインスタントクローンを作成するまでの手順をお伝えしたいと思います。




vSphere6 Update2 リリース!

3/15に予定通り、vSphere6 Update2がリリースされました!

期待すべきは、VSAN6.2の機能が搭載されたのだと思います。
VSAN6.2に関しては、VSAN6.2のリリースノートに細かく記載されています。

VSAN6.2 リリースノート
http://pubs.vmware.com/Release_Notes/en/vsan/62/vmware-virtual-san-62-release-notes.html

では、さっそくESXiのリリースノートを見てみましょう

<新機能>
  • 高速ネットワークの対応
    ESXi 6.0 Update 2 は 25 Gと 50 G のイーサネット リンク速度をサポートするようになりました。
  • VMware Host Client
    VMware Host Client は HTML5 クライアントであり、単一の ESXi ホストに接続してそのホストを管理するために使用します。管理タスクを実行して、仮想マシン、ネットワークおよびストレージなどのホスト リソースを管理できます。VMware Host Client はまた、vCenter Server および vSphere Web Client が利用できないときに、個別の仮想マシンまたはホストをトラブルシューティングする場合に役立ちます。
と、新機能はこれだけしか記載がありません。
(VSAN6.2はどこに行ったと思ったら別のリリースノートに記載されています。
http://pubs.vmware.com/Release_Notes/en/vsan/62/vmware-virtual-san-62-release-notes.html

では、改善された事項を確認しましょう。

<解決した問題>
  • サードパーティ ソフトウェア ServerView RAID Manager を使用する際に、ハードウェアの監視に失敗することがある
  • [ハードウェア ステータス] タブが応答を停止し、エラー メッセージが表示される
  • PowerCLI を使用して esxcli コマンドが実行されると Hostd が応答を停止する
  • ESXi ホストでパープル スクリーンに CMCI (Correctable Machine Check Interrupt) メッセージが表示される
  • vSISH の統計情報に大量のパケット ドロップが表示される
    整数オーバーフローにより、vSISH の統計情報に誤検知された大量のパケットドロップが表示されることがあります。
  • vDS 環境で、vMotion が LAG を削除した後に失敗する
  • ESXi ログ バンドルの収集中に、ファイバ チャネル オーバー イーサネット (FCoE) のリンクが停止することがある
  • Hostd のログに、短時間に連続して複数回エラー メッセージが出力される
  • ESXi mClock I/O スケジューラが期待通りに動作しない
  • 複数の AppStack を接続しようとすると長い時間がかかる
  • VDDK HotAdd 転送モードを使用して、仮想ボリューム上で 2 TB を超えるディスクを開くことができない
  • IPv6 セットアップに I/O フィルタをインストールすると、その機能が VPXD に発行されない
  • Virtual SAN クラスタのホストを ESXi 6.0 Update 1b にアップグレードした後、クラスタの一部のホストで誤った警告が報告される
  • vSphere Web Access から、パワーオンされた仮想マシンへの仮想マシン コンソール接続を開始できない
  • 3D アクセラレーションを有効にしたホストで Hostd がランダムに応答を停止する
  • 永続的なデバイス損失の影響を受けた仮想マシンがフェイルオーバーしない永続的なデバイス損失 (PDL) の影響を受けた仮想マシンがフェイルオーバー ホスト上でパワーオンしません。仮想マシンをホストするストレージに PDL がある場合はハードウェア バージョン 1 が認識されない、という警告メッセージが表示され、仮想マシンは無効な状態のままとなります。
  • 3D ハードウェアを備えた ESXi ホストがメンテナンス モードに移行し、vMotion がトリガされると、Hostd が応答を停止することがある
    2 台の 2 TB 仮想ディスクを備えた仮想マシンで vMotion を実行することができない
    ディスクのみのストレージ vMotion 中に仮想マシンが応答を停止するか、パワーオフ状態に移行することがある

AppVolumesのAppStackを複数接続すると時間がかかる問題も解消されているのは大きいところですね。

既知の問題は特に大きなものは上がっていないようでしたので、今回は割愛します。
より細かい情報は、リリースノートをご覧ください。

VMware ESXi 6.0 Update 2 リリース ノート
http://pubs.vmware.com/Release_Notes/jp/vsphere/60/vsphere-esxi-60u2-release-notes.html



Embedded Host Client ついに、vSphere6 Update2で、「VMware Host Client」として正式リリース!

昨年より、アップデートが入るたびに適宜投稿しておりました「ESXi Embeded Host Client」ですが、先日のvSphere6 Update2のリリースとともに正式にvSphereファミリーの1つのコンポーネントとしてリリーされました。


リリースノートにも記載され、「VMware Host Client」という名前になったようです。

MyVMwareからVMware Host Clientを入手することが可能です。


インストール方法は今までと同じです。VIB形式での提供ですので
esxcli software vib install -v /xxx/yyy/VMware-Host-Client-1.0.0-3617585.vib
でインストール可能です。(vibファイルはあらかじめ、ESXiホストのどこかに置いておく必要があります)

Host ClientのURLは、
https://esxiホストのIP or FQDN/ui/
です。

さっそくUIのバージョン情報を見ると
2016年3月2日リリースとなっており、ビルド番号は「3617585」となっています。

ただ、FLINGSでの、Embeded Host Clientは継続してリリースされており、最新版は「2016/3/4」 にリリースされています。ただし、ライセンスは継続してTechnical Previewとなります。


FLINGSを見ると、ビルド番号は、3623722となっており、正式リリースよりも新しいのがわかります。

今回のvSphere6 Update2にて正式にHost Clientとしてリリースしたことにより、次期バージョンのvSphereからいよいよC#版vSphere Clientはリリースされなくなることが濃厚になってきましたね。


まだ、ESXiホスト単位でしか管理ができませんのが、正直Flash版に比べてものすごく、操作性が良いので、是非一度使ってみることをお勧めします。

昨年のVMWorldで、vSphere Web ClientがHTML5ベースになるという話が発表されましたが、これがベースでできるのかもしれませんね。次はvSphere Web ClientのHTML5化に期待です。






2016年3月5日土曜日

NSX for vSphere 6.2.2リリース!

かねてよりリリースが噂されておりました、NSX for vSphere 6.2.2が2016/3/3にリリースされました。


今回の変更点は、
  • CVE-2015-7547(glibcの)セキュリティパッチが適用
  • NSX EdgeのDHCPドメイン名の構成上の制約の変更。
    (ドットやハイフンなどの文字が入ったドメイン名称を指定できるようになりました。)
    詳細は、VMware KB 2144097を参照。
  • より優れたユーザーエクスペリエンスのためDFW UIの機能強化。
と記載があります。

特にに3つめの分散ファイアーウォールのUI変更というのは実に気になります。

併せて、バグ修正が行われております。

  • netcpaソケットが閉じられ、VMがVNIsを介して通信するために失敗する。
     
  • DFWルール/ IPリストの更新が原因で、NSX Managerでタスクフレームワークリソース制限のためにスケジュール(配信)することができませんでした。

  • トラフィックがESGのHAフェイルオーバー後に50秒間中断される。
    NSX ESGは、HA NSXのエッジノード間のスタティックルートを同期させるために失敗したときに、この問題が発生しました。
     
  • ESGロードバランサIP_HASHヘルスチェック発行選択したバックエンドサーバの重みが0に等しい場合、ソースIPハッシュアルゴリズムを使用している場合、「サービスを使用できません」というエラーメッセージが表示される。ヘルスチェックで有効なバックエンドサーバがある場合でも、このメッセージが表示される。
     
  • NSX NetXで、パートナーデバイスにトラフィックをリダイレクトするためにルールを追加することはできない問題を修正。
     
  • DFWなしNSX NetXをを使用しするとDVFilterでエラーが発生しました。
    詳細は、VMwareナレッジベース KB:2144018を参照。
     
  • NSX 6.2.1で、NSX Managerを追加しても、vDS(分散スイッチ)のライセンスが有効にならない問題を修正。
    詳細については、VMwareナレッジベース KB:2143397を参照。
     
  • DHCPユニキャストパケットがDHCPリレーが有効になっている場合、実際の受信LIFは、DHCPリレーが有効にならない。
    LIFのIPにアドレス指定されている場合はESXiホストはPSODになる。
    詳細は、VMwareナレッジベース KB:2144314を参照。
     
  • VXLANハイブリッドモードでは、コントローラの断線が間違ってマルチキャストモードにフォールバックトリガされる。
    詳細は、VMwareナレッジベース KB:2144457を参照。
     
  • 分散ファイアーウォールで、ルールーが表示されないことがある。
    詳細は、VMwareナレッジベース KB:2141155を参照。

とかなりバグフィックスされています。
とくに、昨年の3月ぐらいに、NSX for vSphere購入者は、vSphereのエディションに関わずvDS(分散スイッチ)が利用可能になったというメリットがあったのですが、この機能がNSX for vSphere 6.2.1のバグでvDS有効にならないという症状は私自身も体験したのですが、なかなか厳しいバグでしたね。vDSが使えないと、NSX for vSphereのほとんどの機能が利用できませんので...。






NSX for vSphereを見てみよう(10) 分散ファイアウォールで"キモ" ダイナミックメンバーシップってなに?

前回は、仮想マシンにタグ付けをすることで、ウイルス感染をした仮想マシンを隔離できるというマイクロセグメンテーションの具体的なメリットについてお話をしました。

ここで疑問になることは、タグが付いた仮想マシンを隔離といいますが、タグは仮想マシンがウイルスに感染したタイミングでした付与されませんし、それとファイアーウォールのルールとどう関係するのかが、謎な話になるかと思います。
 今回はこの謎を解きたいと思います。

さて、この謎を解く大事な鍵は「ダイナミックメンバーシップ」というキーワードです。
(一部では、動的メンバーシップと言われています)

今までのファイアーウォールのポリシーを組む際には

送信元IP宛先IPアクション有効/無効
192.168.1.0/2410.0.0.0/24Deny有効

といった、送信元と宛先でそれぞれIPアドレスを指定してそれに対してアクションを行うこととなります。これですと、仮想マシンにあらかじめタグが付与されている訳ではありませんので、送信元IPを特定することができません。

では、

送信元IP宛先IPアクション有効/無効
"AAA"とtagが付与
された仮想マシン
10.0.0.0/24Deny有効

といったポリシーを書けば"AAA"というタグが付与された仮想マシンは、10.0.0.0/24へのネットワークには通信ができないというポリシーが書ければ成立しますね。
これが、NSX for vSphereで行うことができます。

この「"AAA"とtagが付与された仮想マシン」というのは、ウイルス感染している仮想マシンが0の時は、対象は0ですが、3台の仮想マシンがウイルス感染し"AAA"タグが付与されれば、この対象は3になります。つまり対象となるものが固定されたIPアドレスではなく、状況に応じた条件で指定することができるため、その時々で対象となる仮想マシン(=IPアドレス)が変わることから、「ダイナミック(動的)メンバーシップ(対象範囲)」という表現をしています。

具体的に画面を見てみましょう。


NSXには、Service Composerという「ダイナミックメンバーシップオブジェクト」を作成する機能があります。ここで作成したオブジェクトが従来IPアドレスに変わるファイアーウォールのオブジェクトとして取り扱うことが可能となります。




実際にオブジェクトを作成してみましょう。
作成は、ウィザード方式での作成となります。

1.まずは、オブジェクトの名前と説明(任意)を入力します。

2.ここで動的なメンバーシップ条件を指定します。

ここで、セキュリティタグを指定した場合、タグの内容を入れることで同じタグ名称が指定された仮想マシンが、このオブジェクトの対象となります。
セキュリティタグ以外にも、コンピューターOS名や、仮想マシン名などを指定できます。
たとえば、コンピューターOS名で「Windows XP」と入れておけば、XPの仮想マシンだけを一括りにオブジェクトとして指定することができます。これは、VMware Toolsから情報を拾ってきますので、あらかじめ仮想マシンに対して手動でOS情報の割り当てなどを行うことはありません。

3.指定した条件を割り当てる対象を選択できます。状況に応じて、クラスター単位はリソースプール単位、必要があれば仮想マシンを個別で対象に含めることも可能です。


4.条件を指定して場合、すべてに当てはまると困る場合、除外を指定することができます。除外も、このServiceComposerであらかじめダイナミックメンバーシップを作成しておきそれを割り当てることが可能です。(必要がなければなしでOKです)


5.サマリー表示です。これでオブジェクトの作成は完了です。

では、実際に分散ファイアーウォールに割り当ててみましょう。

6.分散ファイアーウォールの画面を開きます。

7.ルールを追加して、必要に応じて名称を入力します。

8.鉛筆マークを押し、オブジェクトを選択します。

9.オブジェクトを選択します。尚この画面からService Composerのダイナミックメンバーシップオブジェクトを作成することも可能です。

10.今回の例では宛先はIPアドレス指定ですので「IP」ボタンをクリックし、対象のIPアドレスオブジェクトを作成します。


11.あとは、アクションをDenyにして、設定情報反映します。

さて、イメージはわきましたでしょうか?
ファイアーウォールルールは、一般的なファイアーウォールと何も変わらないと思います。
ポイントは、Service Composerで作成した、IPに紐付かないオブジェクト対象である「ダイナミックメンバーシップ」を、ファイアーウォールのソースまたは、ターゲットのオブジェクトとして選択可能ということです。これが、NSX for vSphereの分散ファイアーウォールの最大の特徴です。

さて、こうなると自分でService Composerで作成したオブジェクトがどれだけ対象になっているかを見たいものですね。

確認方法は2つあります。
1つは分散ファイアーウォールのポリシーで作成したオブジェクトをクリックする方法です。

もう1つは、Service Composerの画面から対象数量と細かいオブジェクトを確認可能です。


これで、マイクロセグメンテーションの具体的な設定方法は、理解できたと思います。
今までのファイアーウォールの考え方をそのままに、ダイナミックメンバーシップ機能を追加することで大変柔軟性の高いファイアーウォールが実現できるのは、NSX for vSphereの凄いところだと思います。






NSX for vSphereを見てみよう(9) 分散ファイアウォールでマイクロセグメンテーション

さて、前回に分散ファイアーウォールのお話をさせていただきました。
分散ファイアーウォールは、セグメントに関係なく細かなポリシー設定が可能というのが特徴でした。
これだけでマイクロセグメンテーションといっても間違いではありませんが、よりマイクロセグメンテーションを有効的に利用する方法をご紹介しましょう。

仮想マシン単位で細かいファイアーウォールを設定できるメリットを生かせる場所を考えて見たときに、ウイルス/マルウェア対策との連携があげられます。

環境はFAT-PC(一般的な物理PC)から、シンクライアント環境(VDI)になってきましたが、シンクライアントの場合、稼働している仮想マシンは、ユーザーの手元にないと言うことです。

今までの物理PCの場合、端末がウイルスに感染したら、情シス管理者は「LANケーブルを抜け」という指示を出し、その端末を"隔離"することから行います。
これが、シンクラになった場合、ユーザーにLANケーブルを抜かせる指示をしても、シンクラ端末のLANケーブルを抜いたところで、ユーザーに画面転送がされなくなるだけで、ウイルスを隔離することはできません。

これでは、ウイルスが拡散してしまいます。

これをNSX for vSphereの分散ファイアーウォールとサードパーティーのセキュリティ製品を連携することで、問題を解決することができます。

ウイルス対策などのセキュリティ製品で、ウイルスチェックを行い、特定の仮想マシンがウイルス/マルウェアに感染したと判断した場合仮想マシンに特定の識別タグを付与することができます。

この仮想マシンのタグというのは、NSX Managerが管理する仮想マシン単位で管理できる識別子です。サードパーティーのウイルス対策製品が、ウイルス検出など特定のイベントが発生したときに、NSX Managerに仮想マシンに対してタグを付与する命令を出すことができます。

このタグが付いた仮想マシンだけを分散ファイアーウォールによって通信を遮断するルールを記載することで、ウイルスに完成した仮想マシンだけを隔離することが可能となります。

これで今までの物理PCで可能であった、マシン隔離も自動で行うことが可能となります。
VDI時代になって、データーの持ち出し制限など、情報漏洩に関するセキュリティは解消したものの、こういった仮想化ならではの新たな問題にも対応することが可能となります。

これは、NSX for vSphereとサードパーティー製セキュリティソフトとの連携による、次世代のセキュリティーソリューションだと思います。


NSX for vSphereを見てみよう(8) 忘れてはいけない分散ファイアウォール

NSX for vSphereのお話をすると、どうしても「L2延伸」に伴う、VXLANの話しがメインに感じてしまいますが、もう1つほど重要な機能があります。それは「分散ファイアーウォール」です。

分散ファイアーウォールは、簡単に言うと仮想マシンのNICの前にファイアーウォールが配置されるイメージとなります。

では、今までのファイアーウォールの配置(ネットワーク構成)イメージをおさらいしてみましょう。


こちらは一般的なネットワーク構成だと思います。
内側外側のファイアーウォールを1つで構成しているケースはあるかと思いますが、基本的には、VLANでセグメントを分けて、セグメント間を通信制御するというのが、今までのネットワーク設計でした。

この考え方で出てくるセキュリティの問題は、
  • より細かいセキュリティを構成しようとすると、VLANの数が増えてしまう
  • AppVLANとDB VLANの両方のネットワークに属するような仮想マシンが存在すると、兼務VLANの作成を行うか、VMへのNIC2枚挿しなど、別の手法を利用してネットワークを構成する必要がある
  • バックアップネットワークなどすべてのネットワークに通信する場合、全仮想マシンにNIC2枚挿しを行うことで、セキュリティが形骸化する
といった、問題が出てきます。

かといって、Windows Firewallやiptables/firewalldのようなOSレベルでのファイアーウォールの設定は、仮想マシン単位の設定となり一括管理ができず、現実的ではありません

この問題は、ネットワークを構成する際に「当たり前」として扱われてきた問題でした。

これを、NSX for vSphereの分散ファイアーウォールで解決することができます。


図を見ていただくとわかるのですが、VLANの数も減り、すっきるとしたネットワークになっているかと思います。ただ、セキュリティは、今までのネットワーク設計よりも強固になっています。

そのポイントは「仮想マシンのNIC単位でファイアーウォールを配置される」ことにあります。

この場合のメリットは、
  • 細かなセキュリティのためにVLANを増やす必要が無い
  • 同一セグメントの仮想マシンにおいても、通信制御が可能
  • ポリシーはNSX Managerで一括管理が可能
ということになります。まさに、 今までのネットワークでは、諦めていたセキュリティを手に入れることができます。

これがマイクロセグメンテーションの意味になります。


ビジネスに最適なIaaSはvCloud Air。その理由は?

今までのサーバー販売ビジネスを行っていたSIerにとっては、クラウドというのは商売敵と認識をされているところもあるように耳にします。

クラウドにシステムは移行することで、
  • 一括で大きな利益と売り上げを立てられない
  • いままではリプレース期間までの5年間ロックインができたが、
    クラウドは月額払いなのでロックインすることができない
という悩みから、オンプレミスでのビジネスしか考えていないSIerも未だ多いようです。

しかし、世の中のクラウド機運は高くかつて、汎用機のSEだった人が、パソコンベース時代に移行したように、同じような波は来ていると思います。

それは、vCloud Airには、
  • 複数年一括契約が可能(複数年一括だと当然ディスカウントも)
  • 販売店(vCloud Airパートナー)に対して、仕切販売が可能
  • 支払いは、パートナー経由の支払い(クレジットカードは不要)
という2点のメリットがあります。

特に後者の仕切販売が可能というのは、 他社クラウドと比べて大きな違いだと思います。

複数年一括契約をすれば、ある程度のボリュームで売り上げを立てることも可能です。
支払いは、販売パートナー経由となりますので、エンドユーザーにとっても今までの取引SIer経由で、請求書での支払いが可能となるため特別な経理手続きや企業クレジットカードの用意は必要ありません。
エンドユーザーにもSIerにとってもメリットがあるのが、vCloud Airの特徴です。