大きなメリットは3つあります。重要なパッチの見逃しが無くなる導入・運用全てでリブートが不要システムの運用を行っていると、システム側で再起動がどうしても必要なことが多々あるかと思います。ユーザーはサービスが止まることは望んでおらず、いつでも使いたいと思っています。脆弱性管理は行っていたとしても複数のOSバージョンやディストリビューションが混在している環境だとそれぞれに対してパッチの適用を行う必要もでてきますし、Kernelの更新時にほかの昨日もアップデートされ、アプリケーションに影響がでないかと気にする必要がでてきます。KernelCareはメリットにもあるように、既存のシステムに対して簡単にインストール(事前検証は必須です)でき、Kernelの脆弱性について自動でパッチ適用し、既存のアプリケーションにも影響を与えないということを再起動不要で行うことができます。サポート対象OS現時点でのサポート対象OSは下記のようなものがあります。※詳細バージョンはお問い合わせください。多くのLinuxディストリビューションをサポートしています。パッチの作成はだれが行う?Kernelのパッチ作成はKernelCareの開発元である、CloudLinux社が行っています。カーネルに適用されます。カーネルアドレススペースにパッチをロードし、実行パスをオリジナルのコードブロックからアップデートされたコードブロックへと安全に切り替えるという仕組みで動いています。メモリ上で展開しているので、再起動するとパッチは消えてしまいますが、再起動直後にKernelCareエージェントがパッチを取得し適用します。アプリケーションに影響がないのはなぜ?パッチが提供するのは脆弱性部分についてのみで、その他のカーネルの機能にはパッチを提供しないためです。よって、カーネルのバージョンもあがりません。動作の仕組み今回投稿しませんが次回以降に大規模やエアギャップな環境に導入する方法についてご案内いたします。事例は?そんなクリティカルな製品だと事例を聞きたいですよね。採用企業はハードウェアベンダー、インフラ系事業者、クラウド事業者、ホスティング事業者、などになります。採用理由はメリット部分が主な理由でセキュア、ダウンタイムなしなどやSOC2準拠などがあります。まとめ今回、さらっと製品の説明をしました。別途製品説明資料が欲しい!といったご要望や脆弱性対応どうしよう?とか古いLinuxがそのまま残ってる・・・などなどLinuxの脆弱性対策をお考えの方はぜひ弊社までご連絡ください。Webでのお問い合わせはここからになります。次回以降インストール方法など使い方や他製品との連携についても投稿していきますのでよろしくお願いします。AD連携機能を試してみるみなさん、こんにちは。今回はユーザー連携部分のお話です。この手の製品の管理コンソールですとユーザーの作成はローカルとLDAPと連携する方法があり、ICPも同様です。連携も対応していますので、ちょっとセットアップしてみたいと思います。環境ICP環境は前回、前々回などと同じ環境です。Directoryを用意しています。画面はこのようになっています。今回のゴール下記のことができるように確認します。所属しているユーザーでログインができること登録したユーザーには特定のリソースしか表示、利用できないことADを登録ICPでのLDAPの登録は管理コンソールからできます。管理コンソールにログインして、メニューの[管理]-[IDおよびアクセス]に移動します。接続の作成をクリックします。下記の内容を参考に設定します。DNがわからないという方は、下記のようにコマンドプロンプトから確認したユーザーを入れてみてください。入力後、接続の確認をして、保存します。次にチームを登録します。チームに対して、AD上のユーザーやセキュリティグループを割り当てたり、利用可能なリソースの割り当てを行います。メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。チームの作成をクリックします。ポップアップウインドウで下記を参考に入力します。作成をクリックします。チームが登録されることが確認できます。チームに登録されているセキュリティグループの確認さきほどのチーム登録時に指定したセキュリティグループicpgroupが登録されていることと、グループに登録されているユーザーもICP上で確認可能か見てみます。管理コンソールで作成したチーム名をクリックします。今回であれば、icp-teamです。チームに登録されているグループの一覧が表示されます。1グループしか登録していないので、icpgroupのみが登録されています。icpgroupをクリックします。icpgroupに所属しているユーザーの一覧が表示されます。セキュリティグループに登録されているユーザーのログイン確認セキュリティグループに登録されているユーザーもICP上で確認できましたので、そのユーザーでICP管理コンソールにログインできるか試してみます。今開いている管理コンソールをログオフするか、別の種類のWebブラウザまたはシークレットモードで起動したWebブラウザを起動します。※あとの工程上、ログオフせずに別のWebブラウザまたはシークレットモードのWebブラウザのほうが都合がよいです。ログイン画面で先ほど確認したセキュリティグループに登録されているユーザーでログインします。ログインでエラーがでることもなく、管理画面のようこそ画面が表示されることが確認できます。次に、作成済みのチームicp-teamにADユーザーを個別に登録してみます。ICP管理コンソールを開き、adminでログインします。メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。その後、icp-teamに移動し、ユーザータブを表示します。ユーザーの追加をクリックします。下記を参考にユーザーを検索します。検索結果が表示されていますので、今回はuser3を選択します。このユーザーはセキュリティグループicp-teamには登録されていないユーザーです。役割のカラムで役割をドロップダウンリストから選択できます。今回は管理者のまま、追加をクリックします。ユーザーの一覧画面が表示され、ユーザー登録が完了していることが確認できます。登録したユーザーでログインしてみる登録したユーザーでICP管理コンソールにログインできるか確認してみます。今開いている管理コンソールをログオフするか、別の種類のWebブラウザまたはシークレットモードで起動したWebブラウザを起動します。※あとの工程上、ログオフせずに別のWebブラウザまたはシークレットモードのWebブラウザのほうが都合がよいです。先ほど登録したuser3でログインします。ログインでエラーがでることもなく、管理画面のようこそ画面が表示されることが確認できます。リソースを見てみるせっかくなので、user3で操作できるリソースを見てみます。space)が割り当てられていないので操作ができません。チームに対してリソースの割り当てを行います。管理者アカウントでICP管理コンソールにログインし、メニューの[管理]-[IDおよびアクセス]-[チーム]に移動します。その後、icp-teamに移動し、リソースタブを表示します。リソースの管理をクリックします。リソースの管理画面が表示されます。defaultとibm-chartsにチェックを付け、保存します。再度、user3でICP管理コンソールにログインします。メニューの[ワークロード]-[デプロイメント]を開きます。先ほどとは違い、エラーは表示されません。実際にリソースが利用できるか確認してみます。管理コンソール右上のカタログをクリックします。構成をクリックし、下記のパラメーターを入力します。Helmリリースの表示を開き、少し時間をあけてステータスを確認します。デプロイメントのステータスの使用可能が1になっており、ポッドのステータスもRunningになっていることが確認できました。先ほどのHelmカタログからデプロイする際のターゲット名前空間のドロップリストはDefaultだけになっていましたので、user3ではdefault以外の名前空間のリソースに対しての権限を持っていないことも確認できました。以上がAD連携の連携後の簡単な動作確認の方法でした。NameSpace(名前空間)ごとに割り当てチームを決めることで、別のチームのNameSpaceへの影響も抑えられますし、そもそもユーザー管理をICP上でコツコツやるのは大変!という要望にもこたえられるかと思いますのでぜひ試してみてください。現状の挙動として、ちゃんとAD上に存在していて、ICP上のチームに登録されているセキュリティグループにも所属しているADユーザーでもログインできない場合は、一度ICP上のADの登録画面で対象のADを編集で開き、再度保存してみてください。今回も長々とありがとうございました。Advisorを追加してイメージの脆弱性をスキャンしてみようこんにちは。Privateについて、かなり間が空きましたが、前々回にインストールの内容を投稿しました。Advisor)を追加してみたいと思います。脆弱性アドバイザーって何?ドキュメント上では下記のように説明されています。サード・パーティーによって提供されるか、組織のレジストリー名前空間に追加された、コンテナー・イメージのセキュリティー状況を検査します。各クラスターにインストールされている場合、脆弱性アドバイザーは、実行中のコンテナーの状況も検査します。https://console.bluemix.net/docs/services/va/va_index.html#aboutICPで管理しているイメージや稼働しているコンテナー上で脆弱性をもつパッケージがないかと設定について問題がないかをレポートしてくれます。この機能の開発は日本のラボで開発されているとのことです。Advisor(VA)を追加して、イメージのスキャンとコンテナーのスキャンまでできることを確認してみたいと思います。既存環境が存在しており、その環境にWorkerノードを追加構築していく想定の手順となっていますので、環境がまだないという方はインストール方法を参考に作ってみていただければと思います。Privateを想定した手順となっておりますので、CE版での実施は想定しておりません。(VAはCE版では利用できません。3.1.1の環境をベースに作成しています。前回投稿したICPのインストール手順では3.1.0を利用していますが、今回手順については3.1.0でも変わりませんので、各コマンド部分の3.1.1部分を3.1.0に読み替えて実施してみてください。脆弱性アドバイザー(VA)のインストール既存環境サーバースペックは同じもので2台のサーバーがあります。Serverが1台ずつあります。ICPのバージョンは3.1.1になります。以前、投稿した手順は3.1.0になります。3.1.1でも同様の手順でインストールできます。読み替えて手順を実施してください。事前準備WorkerやVAにするノードを準備します。今回は以既存環境と同じスペックのRHELの仮想マシンと同じものを用意します。動作は可能(VAは制限あり)ですので、動作環境の詳細は下記をご参照ください。https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.1/supported_system_config/supported_os.html追加するノード追加するノードは下記になります。追加するノードでは下記の事を行います。下記コマンドを実行してなにも表示されないことを確認します。LinuxとFirewallを無効化します。disableに変更します。Firewallは下記のコマンドを実行します。追加するノードと既存のサーバー群と時刻の差が出ないように時刻同期を行います。時刻同期方法は各Linuxのドキュメントをご確認ください。RHELで時刻、時刻同期の設定の確認は下記コマンドでできます。インストール(の確認)Pythonがインストールされていることを確認します。サポートされているPythonのバージョンは、2.6,2.7,3.5以上になります。2.7.5DockerのインストールDockerをインストールします。DockerのバイナリーはIBM社から提供されています。141MBこのファイルをノード上にコピーし実行します。--install※このとき、内部で別のコンポーネントをyumでインストールします。dockerが自動起動されるように設定します。Serviceの再起動を行います。後述の手順内で再度ご案内します。Serverから行います。Keyをコピーします。<user>@<node_ip_address>今回は、下記の情報を使ってコマンドを実行します。Serviceを再起動します。下記にLinux用のバイナリーファイルがあることを確認します。インストールパスを変更している場合は適宜読み替えてください。ibm-cloud-private-x86_64-3.1.1.tar.gzVAの追加VAの追加は下記のコマンドを参考に実行します。VAとして追加しますので、実行するコマンドは下記になります。追加したノードがVAとして登録されているか確認します。ICP管理コンソールから[プラットホーム]-[ノード]を開きます。記載されていることを確認します。ServerとVAノードに機能をデプロイ(アドオン)します。Server上のConfig.yamlを編集します。disabled下記の内容を参考にコマンドを実行します。addonDockerイメージ名が異なりますので、下記のように変更して実行します。addonVA動作の確認VAの機能追加完了後は、管理コンソール上でスキャンの状況やレポートが確認できるようになります。管理コンソールのログアウト/ログイン管理コンソールにログインした状態で機能の追加を行った場合は画面が正常に表示されない場合がありますので、管理コンソールからログアウトし、再度ログインします。コンテナーイメージのスキャン状況の確認VAの機能が有効化されると自動的にコンテナーイメージのスキャンが実行されます。すべてのイメージをスキャンするには時間がかかりますが、スキャン済みのものからステータスの確認ができますので開いています。管理コンソールを開きます。メニューから[コンテナー・イメージ]を選択します。ステータスがあるものはスキャンが完了しています。スキャンの結果、問題がいくつあるか表示されています。スキャン結果のレポートが表示されます。Policiesでは違反理由が表示されています。今回はイメージ内にインストールされたパッケージ上に既知の脆弱性が含まれていることが示されています。Packages]のタブをクリックします。ここでは脆弱性の影響を受けるパッケージの情報が表示されます。Settings]のタブをクリックします。ここではコンテナーの設定に対して潜在的な脆弱性の問題や推奨されてる設定について表示されます。Analysisの情報も確認できます。次に稼働しているContainerのスキャンレポートを確認します。管理コンソールから[ツール]-[脆弱性アドバイザー]を選択します。※ツールメニューが表示されない場合は管理コンソールのログアウト/ログインを行ってください。[kube-system]を選択します。Containers)]が表示されます。なっているリストをクリックします。以上がVAの展開からスキャンの結果の表示までの手順になります。いうContainer上で変更があった場合に検知する機能もあります。今後、検証する予定ですので、別途レポートを投稿したいと思っています。Image自体にセキュリティ上の問題がないか、設定上にも不備がないかもチェックしていかなければならないかと思います。AdvisorはICPに付属している製品ですので、ぜひ試してみてください。PrivateのPoC環境の貸し出しも実施しています。https://www.networld.co.jp/product/ibm-hardware/trial/Web上にVA機能についてのPoCについて記載はありませんが、PoC環境でVAも使って検証してみたい!といったご要望がありましたら問い合わせ窓口からご相談ください。Blogの記事の翻訳ヴァージョンです。Patchesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。火星でのバケーションから戻ってきた、というようなことでもない限り、最近もっともモダンなCPUアーキテクチャ上で発見されたセキュリティの脆弱性に関する様々な雑音や混乱から逃れるということはできないでしょう。これらの脆弱性ーSpectreとMeltdownーは3つにカテゴライズされており、ソフトウェアのパッチが必要であり、終息についてはマイクロコードのアップデートが必要です。研究の最初の一歩としてはうってつけです。このパッチは何故今までの元は異なるのか?この理由はSpectreとMeltdownの脆弱性がいずれもCPUのアーキテクチャに関連したものだからであり、これを終息させようとすることはOSやアプリケーションが近年のCPUの投機的な実行機能を利用する方法を調整するということまでもが含まれてくるからです。ゲストOSのベンダーはそのお客様に対してこれらのパッチを当てることによるパフォーマンスへの負の影響について声高にのべており、不安定になってしまうことを理由に最初のパッチを取り下げたベンダーも見られます。SpectreとMeltdownによるパフォーマンスの劣化の最終結果を完全に理解することになるにはまだ時間が足りませんが、私は皆様に対して、完全にそれを検証し終えること無くパッチの適応を急いではならないと警鐘を鳴らしたいと思います。パッチを当てる対象はハイパーバイザー、ゲストOS、そしてマイクロコードレイヤが含まれ、アップデートを充てる際には、まず、最低でも評価の手順のフェーズを終えて、それぞれのパッチの影響を理解して行うべきです。このフェーズ化されたアプローチはそれぞれのパッチ、そしてその組み合わせが安定性を備えるまでの時間という意味でも、より大きな環境へとそれを適応していく前に行うことは理にかなっています。Proがどのように役立つのか?このブログ記事の本筋に立ち戻りましょう。Proを利用することで、今日の皆様の環境とパッチを当てたあとの状態の環境とのCPUの利用率の上昇差分について理解していく手順をシンプルにしていくことができると考えています。どの時間をみて、(そして)どのような変化が起こりそうか、ということがわかっているのであれば、通常のパフォーマンスチャートでそのイベントの影響を見ることができます。以下の例にあるように、一番上のチャートは選択した仮想マシンの3時間の間隔でのCPUの利用率の様子を顕しています。矢印のマークの部分ではこの仮想マシンのCPUの利用率が驚くほど上昇していることがわかります。利用率が上昇したという事実については理解が難しいものではありません、しかし、チャートはこの変化が通常こうしたものであるのか、それともこの環境における変化がこの程度なのか、ということを顕しているわけではありません。Proへ追加しました。管理機構は今は仮想マシンやホストの通常どのように振る舞っているかを学習できるようになっています。振る舞いを学習したシステムが監視している特定の計測値が通常の振る舞いの領域幅をはみ出したと判断した場合、これは不具合として記録され、警告が発報されます。次の例も上でお見せした同じ仮想マシンにおけるシナリオですが、今回は新しい、インテリジェンスを備えたチャートを利用しています。以下のチャートでは濃いブルーのラインが実際のCPUの利用率を顕しており、青い影の幅はこの仮想マシンの通常時のCPU利用を学習した上で生成されたベースラインを顕しています。チャートの一部にズームイン(赤い円の中へ)してみると、同様にCPUの消費率がスパイクしていることが表されています。この新しい情報の中では、この値が学習されたベースラインを上回って上昇しているということがわかります。不具合が明らかで、この仮想マシンにとって通常の状態でないということですから、アラートが発行されます。振る舞い学習のアルゴリズムはNutanixのX-Fitに組み込まれており、定期的に今回取り上げた仮想マシンを確認して、CPUの増加が継続していることを示しています。すれば、Prismは変更されたCPUの利用率がこの仮想マシンにとって通常の振る舞いであるということを学習し、ベースラインをそれに合わせて以下の例にあるように適切に調整し始めます。利用量が増えていますので、変更後のベースラインは最初はもっと大きな幅になります。この幅はPrismが仮想マシンの監視を継続指定国津入れて自動的に調整されていきます。これまでのところ、我々があげてきた例では単一の仮想マシンの振る舞いに注目してきました。単一の仮想マシンのチャートを見るということは非常に有用ですが、多くの組織ではSpectreとMeltdownの脆弱性に対処するために百から数千の仮想マシンにパッチを当てる必要があります。した修正を展開してその影響について監視していくという範囲の大きさを考えれば、注目すべき点は自然により高いレベルになっていくことでしょう。した場合のシナリオではホストレベルで環境を見ていくほうが時間を短縮することができる一方で、それぞれの変更の結果を追跡するということもまだ、できるレベルでしょう。パッチの影響についてホストレベルで見ていくことができるということを示すために、環境においてCPUの利用上昇をシミュレーションする仮想マシンのグループを利用しました。以下の例ではホストレベルのCPUの利用チャートと学習されたベースライン、そして最後に利用率のスパイクが表示されています。このスパイクはホストレベルでの不具合アクティビティとして記録されており、その実態は我々がこれまで上で見てきた仮想マシンです。それぞれのこうした不具合のイベントはPrism内にアラートを作成します。Emailによる通知が設定されていれば、emailアラートとして送信されます。この警告システム自体は非常に有用なものですが、Prismはそれに加えてその不具合の所在についてその不具合にどのような要素が関連しているかを付属させることで簡単に理解しやすくしてくれています。Prismダッシュボードの影響を受けたクラスタのウィジットはクラスタの健全性についての高いレベルでの詳細を提示します。以下のスクリーンショットを見ていただければ分かる通り、直近24時間無いでの不具合の数を1つのデータポイントが顕しています。ウィジット内の不具合数をクリックすると、以下の例のようにその期間における不具合のそれぞれとどの計測値が不具合に該当したのかということも一つのリストにして見ることができます。それぞれの不具合をクリックすれば上で仮想マシンやホストの例で見てきたようなチャートへとアクセスすることができます。組織はゲストOSにパッチを当てることで他のクラスタに対して影響を与える可能性のある決して小さくはないCPU利用率の上昇を理解し、その計画を建てなくてはなりません。Proのキャパシティプランニングの機能によって、クラスタにこうした追加の要求を加えることで、シナリオをモデル化することができます。この例では我々はテクストクラスタのシナリオを作成しました。以下のチャートは現在の環境においての見通しの詳細といかにリストされている既存のホストリソースを顕しています。浪費されているリソースを回収するモデル化されたノードの追加が要求に答えるためには必要よりも大きなものであったり、そうでなくても置かれている状況下において理想的な解決策であるとはいえない場合、浪費されているリソースを回収することを考えることもできます。Proは最適化もしくは回収できるリソースを特定する時にわかりやすいデータを提示します。次のスクリーンショットは全体、もしくはクラスタごとのレベルでリソースの最適化について示しているウィジットです。この例ではoverprovisionedとinactiveに分類された仮想マシンに注目します。いうのも、これらいずれのカテゴリーも組織が合理的に回収し易いリソースを含んでおり、簡単に要求の増加に応えることができます。over-provisioned分類は先に述べた学習した仮想マシンの振る舞いの機能を利用しており、常日頃、割り当てられたリソースのうち本の限られた量しか利用していない仮想マシンです。inactive分類は最低30日間電源が入っていない状態が続いた仮想マシンが特定されています。このカテゴリも学習した仮想マシンの振る舞いを利用しており、電源が入っていたとしてもCPUとディスクの活動が最低量のみを使い続けているというものも含まれています。それぞれの分類のいずれかをクリックすると、Prism上の探索ビューでそのカテゴリに分類された仮想マシンが一つのリストとして表示されます。以下の救いリーンショットはoverprovisionedの仮想マシンを表示しています。この表示から、どの仮想マシンがまさにoverprovisioned(割当過剰)になっているのか、それがどれぐらい多すぎるのかということを簡単に見ることができ、アプリケーションチームとの議論の末にこうしたリソースを回収する計画をたてることができます。リソースの割当の変更を適応する準備が整ったら、単純に仮想マシンを選択して、必要なレベルにリソースを調整するだけです。環境のインベントリを取得するこれまでに関しとキャパシティプラングについて見てきました、最後に取り上げなくてはならないのは環境のインベントリを取得する方法です。ご自身の環境内にどのようなものがあるのかということを理解し、どうしたコードをそれぞれが走らせているか理解することはアップデートのフェーズの準備、そして効果を確認していくためには重要です。Manager(LCM)を利用して、クラスタで動作しているそれぞれのノードのBIOSのヴァージョンのレポートを得ることができます。この詳細情報はどのノードがアップデートを必要としているのかということと、どのノードがアップデートを終えているのかということを理解するためにも重要です。Centralの探索機能を利用して、環境内のホストのリストをハイパーバイザーとそれぞれのヴァージョンを表示しています。Prismはクラウド時代のために作成されているため、マルチハイパーバイザーの管理をネイティブにサポートしていますし、それら全てを単一の画面から表示することができるようになっています。Proはアドホックベース、もしくはスケジュールでの両方でレポートの生成を行える機能を搭載しました。Proにはいくつかの標準レポートが既に含まれていますし、管理者が新しいレポートを簡単に作成することも可能です。既存のレポートをクローンして作ることもできますし、ビジュアルレポートデザイナーを利用してレポートのコンポーネントを利用可能なウィジットのリストの中から選択するということも可能です。以下の1つ目のレポートはセキュリティパッチのウォッチリストです。このレポートはクラスタのCPUのキャパシティの見通しのチャートを利用して、それぞれの変更がどれだけ残されたキャパシティへ影響をあたえるのかということを表示しています。その次はラインチャートを利用して、それぞれのホストごとのCPUの特定の期間での消費状況を表示しており、レポートの対象機関内で増加したものについてはハイライトしています。このレポートは環境内のすべての仮想マシンの個々のCPU利用率も含まれており、仮想マシン単位での影響についても確認が可能です。report更に環境内のすべてのノードのハイパーバイザーとそのノードで稼働しているバージョンをリストでご提供する2つ目のサンプルレポートも作成いたしました。我々はこうした詳細をPrismのインベントリのサンプルで既に目にしていますが、これをレポートにすることでemail経由で自動的にスケジュール通りにより大きなチームへとPDFフォーマットで共有することができます。複数のレポートを単一の大きなレポートに統合するということも必要があれば可能です。ProがSpetreとMeltdownの脆弱性の影響を確認するのにどれだけ有用かということを議論できることを大変嬉しく思います。議論をしたい、もしくはもっと詳しく知りたいということであればコメントを残していただくか、担当営業チームへとご連絡下さい。Proの使い方ですし、何よりも今もっとも重要な脆弱性についての対策の記事ですので予定を変更してお届けいたしました。パッチを当てた範囲が想定内なのかどうか、ということもそうですし、どのぐらい影響があるのか・・・これはスナップショットやクローンを使って仮想マシン毎に見てみるというようなことも重要かもしれません。(ただし、アプリケーションによってCPUの投棄実行が行われるというケースもあるので、パッチを当てた後に実際にアプリケーションを動かしてみるということも必要でしょう。Proですが、本当に素晴らしいソフトウェアに成長してきました。ご検討いただけますと幸いです。Marketplaceはどのように開発者とIT部門を一緒にするのか?本記事はNutanix社のオフィシャルブログの翻訳版です。Togetherをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。ニースにおいて、我々は新しいエンタープライズのための先進的なパブリッククラウドのような消費モデルの開発者中心のサービスを発表しました。この記事では開発者とITをより緊密にするという我々の見通しを共有させていただきます。そこではよりよいコラボレーションが育まれ、アプリケーションの俊敏性が増すことになります。これによって組織に劇的な効果が上がることになるでしょう。開発者とITに共通して必要とされる一般的な目的には市場への迅速な投入の加速、対応時間の短縮、インフラストラクチャの問題の解決に費やす時間の最小化などがあります。開発者は最新の技術の取り込みとオンデマンドなリソースの提供に目を向けがちで、IT側はアプリケーション開発者を手助けする適切なツールの必要性についてはしばし目を伏せがちです。Nutanixは既に管理、アップグレード、ITリソースの拡張のシンプル化などの優れたプラットフォームを提供することで市場への投入時間を短くするという部分については提供をしてきています。Marketplaceが登場してきた意味があります。Marketplaceは我々の2017年Q4でのリリースを予定しています。開発者に一箇所からただのワンクリックで必要なアプリケーションリソースを瞬時に利用開始できるようにします。チームにとっては自身のための特別オーダーメイドとなる様々な展開オプションをユーザーの役割とグループに応じて手に入れることができるようになります。Marketplaceからアプリケーションの1つを起動するということは、MarketplaceやまたはカスタムのITが事前に作成した、事前に定義された全体が自動化された手順のフローをインスタンス化するということです。これには仮想マシン、バイナリ、必要なアプリケーション構成が含まれています。これを利用することで開発者は自分自身の必要とするスピードで完全にセルフサービスの状態でサービスを利用することができます。ITの観点からは、単により良く、迅速なサービスを提供できるということだけに留まりません。アプリケーションはマーケットプレイスからいつも実行可能ですし、再現性があり、数日もしくは数ヶ月のアプリケーションの展開や管理の提携作業を取り除くことになります。すべてのユーザーのアクティビティはエンドツーエンドで追跡可能で、トラブルシューティングや互換性のニーズを解決することにも役立ちます。マーケットプレイスは我々のオープンなアプローチということを前提に設計されています。開発者はアプリケーションをオンプレミスに、もしくはパブリッククラウドにもしくはその両方にまたがっても展開するということを選択することができます。結果としてITはマルチクラウド戦略を実現しながら、その利用状況やクラウドをまたいだリソースのコストについても可視性を手に入れることができるのです。事前統合のBlueprint開発者は常に新たな開発、検証、コード投入の新しい考え方やツールを取り込むことで開発のプロセスを改善しようと考えています。これを最終目標として、Nutanixは事前に統合され、検証の済んだblueprintを提供し、ITチームが新しいテクノロジーを自身の環境に迅速に導入できるようにします。これらの事前統合されたblueprintを用いることでIT部門は開発者とともに新しいツールを迅速に試験導入し、共同でそれを利用するかどうかの決断をすることができます。この能力は新しいツールの実権を育むということだけではなく、チーム間のコラボレーションを生み出すことにもなります。上のスクリーンショットではJenkins、Puppet、Hadoop、そしてMySQLなどの事前統合されたblueprintを確認することができます。NutanixはGoogleとのパートナーシップの中でコンテナのオーケストレーションプラットフォームであるKubenetesのblueprintも提供します。このblueprintではNutanixのオンプレミスとパブリッククラウドの両方へKubernetesクラスタを展開することができます。以下のスクリーンショットでは35ページにも及ぶガイドが必要なほど複雑で、多くのコンポーネントと様々なスクリプトが必要になる厄介な手順がシンプルなblueprintへと翻訳され、マーケットプレイスからワンクリックで利用可能になるということを確認できます。MarketplaceはIT部門に対し、開発者のための優れたセルフサービス環境を実現するための素晴らしい方法をご提供しながら、より良い統制とマルチクラウド戦略への簡単な道筋を提供します。CalmのページまたはCalmの技術メモをダウンロードして下さい。(@Networld_NTNX)今回もニースで発表になった内容の記事となります。Calmはマルチクラウド環境に置けるオーケストレーションを実現するのみならず、スケールアウト、アップグレードなどのアプリケーションライフサイクル全体をコントロールする意欲的なプラットフォームです。Marketplaceです。ワンクリックとある通り、Nutanixの上にこのマーケットプレイスのアプリケーションを展開するのは本当に簡単で、新しい技術を少し試してみようというところから、その先に本格的に導入しようという場合、そしてその環境をパブリッククラウドへと移行させようという場合、様々なライフサイクルの局面で利用することができます。自動化って・・・開発者のものだよねもしくはDev/Opsだよね、というちょっと大変そうな道ではなく、ワンクリックで簡単な道を用意してくれています。閉ざされた自動化が少しでも開ければと思い、私も期待しています。登場が待ちきれません。2017への寄稿も兼ねております。アドベントカレンダーの他の記事もお楽しみください。Odger氏によるものです。Securityをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。セキュリティはXCPの設計において、一つ肝となる部分です。革新的な自動化を利用した結果、おそらく業界で最も堅牢でシンプルで包括的な仮想化インフラストラクチャが出来上がりました。AHVはハードウェアベンダーのHCLを包括的にサポートするようには設計されていません、更にはボルトオンスタイルで数え切れないほどの手間のかかる製品群を積み上げたものでもありません。AHVはそうしない代わりに、Nutanixの分散ストレージファブリックとうまく動くように最適化されており、認証の下りたNutanixもしくはOEMパートナーのアプライアンス上で全てのサービスと機能を完全にウェブスケール式に提供できるようにしてあります。これによって、他のハイパーバイザーと比べ、より緻密で目的にフォーカスした品質管理と被攻撃面を劇的に削減することができているのです。プラットフォームで活用されており、全てのコードの一行一行までが本稼働環境での動作を保証されています。この設計はdefense-in-depthモデルに従っており、すべての必要のないlibvirt/QEMU(SPICE、利用しないドライバー)のサービスは削除されています。libvirtの非-rootグループでソケットは最小限の権限しか付与されないようになっており、SELinuxがゲストのvmescapeからの保護を保証し、その上侵入検知システムが組み込まれています。STIG)をサポートしており、自己修復機能を搭載しています。お客様の定義した間隔でハイバーバイザーはセキュリティベースラインに対するあらゆる変更をスキャンし、あらゆる不都合が検出さればた場合にユーザーを介さずにバックグラウンドでその変更をリセットします。(@Networld_NTNX)第4弾はセキュリティです。ハイパーバイザーはOSの一種ですが、そのうえでさらに多くのOSを起動することを考えると最もセキュリティが必要とされるOSであるということになるのではないでしょうか。AHVは変更検知と自動修復の機能を持ったハイパーバイザーです。不要なドライバーなどは入っていないため、巨大なHCLを抱えるOSに比べて被攻撃面も小さくなります。私自身はセキュリティについて詳しいわけではありませんが、セキュリティ面で見てもシンプルであるが故に、非常に堅牢なハイパーバイザーということは理解できます。折り返しですが、次回の第5段にもご期待ください。ソリューションについてこんにちは。クラウドを活用するデータ保護ソリューションをご紹介します。クラウドを活用したデータ保護については、以前よりも技術面や経済面で敷居が低くなり、他社のバックアップベンダーでも積極的にクラウドの活用を行っていますが、データの転送量や転送にかかる時間、ネットワークの帯域幅など考慮すべき点が多いのも事実です。インスタンスへ自動変換しディザスタリカバリを実現します。製品リリース前のベータプログラムの評価を行いましたので、クラウドを有効活用したDRソリューションをご紹介したいと思います。データ保護ソリューションにおいて「クラウド」と聞いて、皆さんは何を思い浮かべますか?今日現在、クラウド環境内では、セキュリティの対策に加えて、冗長化の構成が進んでおり、より安全性・信頼性の高い環境が提供されていますので、オンプレミスの2次バックアップ先、さらにオンプレミスのディザスタリカバリ先として検討されるケースが増えてきています。Tier」が既に提供されています。クラウドへアクティブ階層に存在していないセグメントのみを直接送信し、データのリコールのためにクラウドから取り出すのは一意のセグメントのみですので、データ転送時のネットワーク使用量を削減することができます。クラウドを組み合わせたデータ保護がさらに注目されてきそうですね。Blogの記事の翻訳ヴァージョンです。Burns氏によるものです。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。本シリーズの以前の記事で、我々はNutanixがどのように仮想化スイッチ内にアプリケーションポリシーを実装し、アプリケーションのトラフィックに対してセキュリティを提供しているのかを見てきました。AHVマイクロセグメンテーションはレイヤ2からレイヤ4までの与えられたポリシー定義をベースにしたルールを実装しています。定義からアドレスやプロトコルやポートを自動的に展開するのです。幾つかのタイプのトラフィックではシンプルなルールでは提供ができない、内部的な検査が必要な場合もあり、そこではネットワークファンクション仮想化(NFV)が必要となってきます。多くのリソースを必要とすることになります。AHVのネットワーキングスタックでは、ネットワークトラフィックフローを収集したり分析したりするために仮想化されたネットワークファンクションを挿入してこうした検査を行うことができます。DCでアナウンスされたワンクリックネットワーク実現するのに役立つAHVの機能を取り上げます。ファンクションチェイン(本記事)AHVネットワークファンクションチェイン現在AHVの管理者はネットワークファンクションチェインをAHVネットワーク(AHVホスト上の単一VLANが対象です)全体からトラフィックをリダイレクトすることで作成します。Exchangeネットワークの全てのトラフィックをファイヤウォールアプライアンスへとリダイレクトすることができます。将来のリリースにおいてNutanixはファンクションチェインがもっときめ細やかなレベルで運用できるようにそしてPrismベースのUIからそれが行えるように計画をしています。した改善の計画についての幾つかについては以下で述べていきます。直近の記事で、アプリケーションポリシーでサンノゼの人事部がExchangeのエッジトランスポート層と通信ができるように許可しました。ファイヤウォール」サービスチェインを使って、ポリシーの作成中に特定のトラフィックをネットワークファンクション仮想マシンにリダイレクトするようにしてみましょう。Westファイヤウォールアプリケーションの検査が終われば、サンノゼの人事がExchangeエッジトランスポート層にアクセスできるようにする」というポリシーを定義することができるのです。上の画像はPrism内のファンクションチェインの管理UIのもので、次のリリース時には利用ができるようになるものです。chain(訳注:サービスチェイン経由でリダイレクト)にチェックを入れることでただのワンクリックでトラフィックを特別なファイヤウォールサービス仮想マシンへとリダイレクトし、さらなる処理を行うことができます。トラフィックが常にこの経路を通ることを保証するために、我々はAHVホスト内の仮想化スイッチ内部にいくつものルールを実装しました。Westファイヤウォールを顕しています。内部のスイッチへと至ります。物理ネットワークへのアップストリームとしてスイッチされます。ーしてネットワークファンクション仮想マシンへと導きます。ブリッジは一つの仮想マシンが他の仮想マシンと直接通信することを一切許しません。特定の仮想マシンからのトラフィックは残りのブリッジチェインを流れながら処理され、ブリッジチェインから仮想マシンへのトラフィックも同様です。ルールを作成し、特定のトラフィックをネットワークファンクションチェイン経由で流せるようになったので、今度はどのようにサービスもしくはエージェント仮想マシンを展開するのかを見ていきましょう。それぞれのネットワークファンクションはそれぞれのAHVホスト上で動作させなくてはなりません。することでサービスチェインをホスト上に構成し、ファンクション仮想マシンを展開して、チェインの中に引っ掛けることができます。この手順を手動ですべてのホスト場で行わなければならないとしたら、こうした手順内では多くのエラーが起こる可能性が含まれてきます。それぞれのステップを手動で実施する必要はありません。Calmが含まれており、これを助けてくれるからです。AHVホスト上にブループリントに沿って展開するだけでなく、必要に応じてコントローラーを構成することもできます。Westファイヤウォールサービスを使い始める際にセキュリティポリシーが正しいことだけをチェックすればよいのです。AHV上で動作しているあらゆる仮想マシンがネットワークファンクション仮想マシンを利用することができます。上で紹介したパロアルトネットワークスのVM-シリーズのファイヤウォールはNutanix上に展開できるNFVの例のホンの一つです。お使いになりたい製品を自由に使うことができます。私のラボではオープンソースのツールを仮想マシンとして動作させ、ファンクションチェインではAHV上の全てのホストにパケットキャプチャとIDSの機能を提供しています。シリーズのサマリ今回のシリーズでは同時にどれだけ可視化、自動化、そしてセキュリティが近年のデータセンタネットワーク戦略の中で重要なコンポーネントになったのかを述べてきました。AHVは接続性とフローマッピングの両方をPrismで可視化しています。自動化はベンダーに依存しないライフサイクルイベント通知とCalmによる複雑なネットワークサービスの展開と構成の両方によって提供されます。複数の段階で階層化された絶妙なネットワークセキュリティを提供しています:接続性とフローの可視化によって怪しいものがないか見つけられるトップオブラック(ToR)スイッチを統合することで、ほんとうに必要な接続性だけが有効になり、必要のなくなった接続性はすぐに削除される仮想化スイッチレベルのポリシーベースのマイクロセグメンテーションで正しいフローのみがネットワーク内で許可される先進的なセキュリティサービスとの統合でこうしたトラフィックをっ更に深く検査することができるCalmの自動化によって管理上の手間を緩和し、先進的なセキュリティサービスまたはNFVのシンプルな展開を可能とするこうしたネットワークの機能を組み合わせることでワンクリックネットワークは現実のものとなるでしょう。コメント(※訳注、日本語版のコメントはぜひ当社のTwitterへ)かNutanixのTwitterにお願い致します。技術的にもっと深く知りたいのであれば、今はまだここまでです。議論を続け、皆でオンラインフォーラムでつながっていきましょう。(@Networld_NTNX)今回はサービスチェインについてです。現時点ではVLANを全て引っ掛けてしまうよう実装のようでちょっともったいない感じもしますが、将来的にもっと細かい設定が・・・とあるので期待しましょう。こちらも予想通りCalmでNFV仮想マシンを自動展開・構成できるようです。Calmに対応したNFVであれば展開/構成までがワンクリック・・・本当にインフラに使う時間が削減されそうです。エンタープライズクラウドの最大の導入効果(みなさんが思っているものと違うハズ・・・)本記事はNutanix社のオフィシャルブログの翻訳版です。Think)をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。インフラストラクチャのコストを削減するのではなく(分析によると殆どの組織において、多く利用されているアプリケーションのような予測可能なワークロードに対してはクラウドは効果になることがわかっています)、よりダイナミックになりつつある市場環境でのビジネスにより速く、そして効率的に対応する能力を高めるために。コンピューティング)に対して、インフラストラクチャおよび他の様々な節約によって劇的な削減を実現できるとしています。大きな成果はビジネスの生産性の向上が積み上がり2乗の効果があがっていきます。Applications)」(2017年8月)(レポートはこちらからダウンロードできます)で、エンタープライズアプリケーションをエンタープライズクラウド上に展開することの詳細を調査しています。HXのノードで861の仮想マシンを運用している11の組織に対して行われたものです。2017(ネットワールドによる補足入り)上のチャートから読み取れるように、Nutanixソリューションは素晴らしいインフラストラクチャにおけるコスト削減以外にも、スタッフとユーザーの生産性の向上で優れた削減効果を発揮しています。ビジネスの生産性による削減は俊敏さ、拡張性、そしてパフォーマンスと関連し、全ての効果の中で57%もの位置を占めています。クラウドのような俊敏性とより低いコストとさらなる統制AWSのウェブセミナーに参加すると、この会社がパブリッククラウドがもたらしたスピード向上と俊敏性についてどれだけ頻繁に話をしているかに気が付くとおもいます。(https://aws.amazon.com/what-is-cloud-computing/)から:クラウドコンピューティング環境では、新しいITリソースはただの1つのクリックで利用でき、これはつまり、皆さんの開発チームがリソースが利用できるようにするための時間を数週間からほんの数分へと削減するということを意味します。この結果、組織には劇的な俊敏性の向上がもたらされます。何かを利用したり開発するために費やされるコストと時間が劇的に低減されるからです。Nutanixのエンタープライズクラウドはお客様に低コストで統制のあるオンプレミスの環境とパブリッククラウドのような俊敏性と生産性の両方を実現します。これらの効果によって、会社の情報システムチームは、単に「火を灯し続ける」ことにチームのリソースを費やすのではなく、プロジェクトをよりビジネスに対しての付加価値になるものにシフトすることができます。:「Nutanix環境を管理しているエンジニアは現在1名だけです、以前はここに5人もの人手が必要でした。我々は従来に比べてテクノロジーをビジネスへの貢献という意味では3倍以上の結果を上げており、より多くのビジネスのための機能を提供できています。俊敏性/拡張性/パフォーマンス、ダウンタイムの削減、そしてセキュリティの向上です。Nutanixのお客様はIDCの調査に対してコンピューティングとストレージリソースの展開とアップグレードが飛躍的に早くなり、劇的にスタッフの時間を削減できたと述べています。一方で従来のインフラストラクチャと比べ、特筆すべきほど優れたパフォーマンスを実現しているとしています。情報システム部門がビジネス部門からの要求に常に追従できる能力を備えたことで、売上の向上に貢献しています。「Nutanixでは拡張が簡単です。ストレージが、もしくはもっと設備が必要になったとしたら、単に追加すればよいのです。これはとても重要な事です。いうのも、我々のビジネス部門は追加システムやキャパシティや彼らが必要としているものを待つ必要がなくなるということだからです。結果としてお客様を失うリスクを回避できるのです。Nutanixのエンタープライズクラウドはアプリケーションやサービスの非計画な停止の頻度や時間を削減するだけでなく、災害復旧や障害無害化の能力を向上させることも実現します。調査によると組織は非計画な停止による社員への影響を94%も削減できたとしています。これはNutanixを利用していて生産性を失ったという時間が1年間で4分だけと言い換えることもできます。「Nutanixを利用していて2013年から1度もダウンタイムがありません。ワンクリックアップグレード方式も取り入れています。Nutanixがソフトウェアをリリースする度に新しいソフトウェアアップグレードを実装に取り込むことができていますし、その際にシステムがダウンするということはありません。OSをワンクリックアップグレードするだけなのです。Nutanixは開発ライフサイクルを通じてセキュリティが保たれています。設計と開発から検証と要塞化にいたるまでです。STIG)も開発しており、これによってセキュリティの自動化と自己治癒モデルが実現する耐え、お客様がセキュリティを維持するのに役立っています。「PCIコンプライアンスに関連する監査の観点から、我々は定期的にシステムにパッチを当ててメンテナンスを行っています。Nutanixはこれを実現することを非常に簡単にしてくれます。2017(ネットワールドによる補足入り)俊敏性と市場に対する迅速な投入について大きく影響をあたえるのが情報システム部門スタッフの生産性の向上です。IDCは平均的にNutanixを利用した場合の管理に費やされる時間の削減率は61%であるとしました。「8人の人手が必要な状態からNutanix環境に変えることで2人で管理ができるようになりました。その代わりに我々は店舗のフロアの自動化ソリューションの設計に多くの時間をつぎ込むことができています。従来この作業は非常に手のかかるものでした。ITをビジネスに活用することでビジネスに劇的な結果をもたらすことができています。」Nutanixを利用することでのご自身の効果を計算するIDCの調査はNutanixを導入することによる効果は年間平均で424万ドルになるとしています。(100ユーザーあたり1万2,884ドル)。2万9,395ドル)。レポートを読んでご自身向けのカスタムヴァージョンをこちらのあなた自身の削減についてから入手して下さい。(@Networld_NTNX)今回は前々回と同様にIDCの調査結果からの投稿です。前々回は市場におけるシェアについての調査でしたが、今回はIDCが実施したNutanixの導入効果についてのものです。Nutanixをつかって得られる本当の効果は、Nutanixを使っていない(インフラの管理から時離れたた)時間をつくることができるということになります。当社もロボットを導入したり、AIを利用したりと様々な生産性を高める社内取り組みをしていますが、インフラの導入や管理、復旧などに頻繁に時間を取られているような状況ではこうした取り組みは中途半端に終ってしまいます。生産性の向上は働き方改革を含め今後の日本では非常に重要です。デジタル革命と働き方革命というキーワードは表裏一体で、そこでしっかりとした実績を挙げられるソリューションはなかなかないと思います。