LTN Blog 〜 Lenovo Technology Network 〜

レノボのソリューション・サーバー製品に関する技術情報、お役立ち情報をお届けします

VMware Project Pacific – ゲストクラスターについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。 今回の投稿もVMwareのProject Pacificに関する内容を投稿しようと思います。

 

本記事の原文はもともとLenovoのTechnical Product Marketing Managerで、Lenovo ThinkAgile 製品担当 そしてVMware vExpertとして活動しているBhavin Shar氏によるものです。

原文を参照したい方は、VMware Project Pacific - Guest Clustersをご確認下さい。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

VMware Project Pacific – ゲストクラスター

前回のブログではProject Pacificをご紹介し、スーパーバイザークラスターとネイティブポッドの概念について詳細に説明しました。今回は内容ではProject Pacificの第3の側面であるGuest Clustersについてご説明します。ゲストクラスターを利用することで、Kubernatesクラスターのセルフサービスの配布をすでに使い慣れている同じ宣言型APIを使用している開発者に対してオンデマンドに提供できます。ゲストクラスターを利用すると、開発者が仮想マシンとして実行しているvSphere上の適合したKubernatesクラスターの展開を可能にします。開発者またはユーザーは管理者の介入なしにコントロールプレーンおよびワーカーノードの一部として展開された仮想マシンの数とクラスターで実行されているKubernatesのバージョンを完全に制御することができます。

 

ゲストクラスターがこれらのメリットをどのように提供するのかを理解するために、次の3つのことについて説明します。 

  1. ゲストクラスターコントローラー
  2. クラスターAPI
  3. VMオペレーター

これらの3つのことを理解するために、vSphere上のゲストクラスターを展開するために実行されるワークフローについてみてみましょう。

ゲストクラスターがこれらのメリットをどのように提供するのかを理解するために、次の3つのことについて説明します。

f:id:t_komiya:20200119131255p:plain

ゲストクラスターを展開するためには

  1. ユーザーは以下のようなyamlファイルを展開します。yamlファイルは、ゲストクラスターコントローラーに対して実行されます。ゲストクラスターコントローラーは使いやすく、ユーザーからの複雑さをすべて排除することができる非常に意見の多いレイヤーです。yamlファイルを取り込み、ゲストクラスターマネージャーと連携してクラスターおよびマシンリソースを生成します。他のK8sのyamlファイルと同様に。このゲストクラスターのyamlファイルにはスペックのセッションがあり、ユーザーは次のようなものを定義することができます。
  • コントロールプレーンVMのVMとストレージクラスの数
  • K8sクラスター内のワーカーノードのVMとストレージクラスの数
  • 展開するKubernatesの配布バージョン

f:id:t_komiya:20200119131404p:plain

  1. ゲストクラスターマネージャーがyamlファイルを受信すると、vSphereの管理K8sクラスターの一部として実行されているクラスターAPIコントローラーに要求を転送します。この時点で、スーパーバイザークラスターをクラスターAPIの管理クラスターとして利用できるか、vSphereの各ネームスペースに新しい管理K8sクラスターを展開できるのかはまだわかりません。Google Cloud Anthosを利用する場合、各管理クラスターは最大10個のユーザークラスターをサポートします。この機能が一般的に利用可能になったら、構成の最大値に関するさらに有益な情報を得られると思います。Cluster APIについて詳しく知りたい場合は、Scott Loweの投稿で読むことできます。ただし、要約すると、クラスターAPIはKubernatesがコンテナ―化されたアプリケーションに提供するのと同様の機能をK8sクラスターに提供できます。クラスターおよびマシンのスペックを利用することで、クラスターで実行されているVMの数やK8sのバージョンなどを定義することができ、マシンの展開(K8sでの展開と同様)の概念を利用してK8sのバージョンを無停止でアップグレードすることができます。管理クラスターは突き合わせループ(reconciliation loop)を実行して、現在の状態(VMの数など)がユーザーの定義した目的の状態と常に一致するようにします。

f:id:t_komiya:20200119131432p:plain

  1. クラスターAPIがユーザーの要件を展開する必要のあるVMに変換すると、呼び出しはVMオペレーターに転送されます。VMオペレーターはいわば正念場みたいなものです。VMオペレーターは、ユーザーが定義した仕様を取り込み、vCenterと双方向に対話してVMを展開し、VMを必要なネットワークに接続します。将来、VMwareではユーザーがVMオペレーターと直接対話してK8sクラスターとともにVMリソースを展開および管理できるようにする予定です。
  2. これは、ユーザーがゲストクラスターのyamlファイルを展開するたびに実行されるワークフローです。ゲストクラスターことができます。コントローラーは、管理対象クラスターエンティティを作成します。これは、クラスターAPIによってクラスターおよびマシンレベルのエンティティに変換され、最終的にVMオペレーターによって実際のVMに変換されます。

f:id:t_komiya:20200119131500p:plain

ゲストクラスタークラスターが論理的に分離されるように個別にの非管理ネットワーク、非スーパーバイザーネットワークに展開されます。認証と承認の観点から、ユーザーはvSphere SSO資格情報を利用してクラスターと双方向に対話できます。また、vSphere SSOと既存のHTML5クライアントを使用してゲストクラスターまたはvSphereネームスペースへのアクセスを制御できるため、仮想化管理者にとっても簡単になります。ゲストクラスターと双方向に対話するためには、ユーザーは基本的にSSO資格情報を使用してvCenter SSOサービスからキーを要求します。これにより、SSO資格情報がゲストクラスターに直接公開されることもなくなります。ユーザーがクラスターにアクセスできるようになると、ユーザーはワークロードを展開し、ワーク―VMの数を増加/削減して、クラスターで実行されているKubernatesのバージョンを制御して、ユーザーにセルフサービス機能を提供し、開発者の業務効率を向上させることができます。

 

願わくば、これらのブログ投稿がProject Pacificの理解を深めることができればと願っています。製品が一般的に入手可能になったら追加の投稿をする予定です。次回のブログではVMwareの戦略で「管理」部分とTanzu Mission Controlについて焦点を当ててお話したいと思います。

VMware Project Pacific – Kubernatesをメインストリームに

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日はVMwareのProject Pacificに関する内容を投稿しようと思います。

 

本ブログの原文はもともとLenovoのTechnical Product Marketing Managerで、Lenovo ThinkAgile 製品担当 そしてVMware vExpertとして活動しているBhavin Shar氏によるものです。
原文を参照したい方は、VMware Project Pacific – Making Kubernetes mainstream
をご確認下さい。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

VMware Project Pacific – Kubernatesをメインストリームに
このブログでは、Project Pacificの様々な側面で説明し、開発者とオペレーターの両者がデンターセンター内でKubernates(K8s)を採用するためにvSphereの進化について説明致します。Project Pacificをより理解するためには、次の3つのことについて検討する必要があります。

  1. スーパーバイザークラスター (Supervisor Cluster):この機能により、ESXiクラスターをK8sクラスター自体として使用することでコンテナーをESXiホストで直接実行することが可能です。
  2. ネイティブポッド (Native Pods):K8sに似ていますが、ESXiのコンテナーランタイムがあります。また、1つ以上のコンテナのコレクションがあります。
  3. ゲストクラスター(Guest Cluster):これらはコンテナ―化されたアプリケーションを実行するための現在お客様が使用しているCNCF準拠のK8sクラスターです。

それでは、スーパーバイザークラスターとネイティブポッドについてお話しましょう。スーパーバイザークラスターとVMwareがESXiレイヤーに対して機能強化について理解するために、まず、通常のESXiクラスターがどのように見えるのかを見てみましょう。
(参考:このブログで使用されている画像はすべて、VMworldセッションスライドのスクリーンショットです)

f:id:t_komiya:20200118140044p:plain
各ESXiホストには、ローカル実行されているホストデーモン(hostd)が存在しており、VMを管理し、ホストにAPIを提供します。2つ以上のホストでESXiクラスターを作成し、すべてのホストとその上で実行されているVMをvCenterサーバーインスタンスで管理できます。Project Pacificの一部として、vCenterサーバーとESXiホストの両方に変更が加えられました。
vCetnerサーバーの場合、以下のイメージに示されるいくつかの追加コンポーネントがあります。

f:id:t_komiya:20200118140301p:plain

  1. ワークロードプラットフォームサービス(Workload Platform Service):このサービスは、クラスターのネームスペースの概念を有効にし、ネームスペースと双方向にやり取りするREST APIを公開します。
  2. K8s クライアント バインディング (K8s Client Bindings):ワークロードプラットフォームがK8s APIサーバーと通信できるようにします。オペレーターとして、vSphere HTML5クライアントを引き続き使用して様々な設定行うことができます。このサービスは、これらの設定をネームスペース内のK8sの設定に変換します。
  3. トークン交換サービス(Token Exchange Service): このサービスは、vSphere SSO SAMLトークンを取得して、K8sで利用するJSON Web Token(JWT)に変換します。
  4. イメージのバンドル:コントロールプレーンイメージおよびSphereletバンドルのイメージレポジトリ

新しいvCenterサーバーを展開した後、私の推測では現在のクラスターでvSANを有効にするのと同様に、Project Pacificの機能を有効にできると思います。Project Pacificを有効にするとすぐに、vCenterのワークロードプラットフォームサービスの処理が始まり、sphereletのバイナリをクラスター内の各ノードにインストールします。

f:id:t_komiya:20200118140445p:plain

SphereletはESXiホスト用のkubeletのVMwareによる実装です。kubeletがK8sクラスターの各ノードのポッドのライフサイクルを担当するのと同様に、Sphereletはスーパーバイザークラスターの各ESXiホストのポッドのライフサイクルを担当します。また、ノードの正常性のレポートも担当します。Sphereletのインストールに加えて、vCenterは3つのVMをデプロイおよび構成して、マルチクラスターK8sコントロールプレーンを作成します。ご利用の環境でNSX-Tを実行しているのであれば、異なるコントロールプレーンVM間でNSX L4ロードバランサ―の負荷分散が行われます。
各スーパーバイザー K8sコントロールプレーンVMは、OSS K8sバイナリを使用して構築されていますが、いくつかのサービスが追加されています。

f:id:t_komiya:20200118140346p:plain

  1. スケジュール拡張:オペレーターがポッドをスケジュールしようとすると、スケジューラー拡張はVMware DRSと連携し、スーパーバイザークラスター内でそのポッドを展開する最適なノードを見つけます。
  2. NSXコンテナプラグイン(CNI)およびクラウドネイティブストレージ(CSI):これらのCNIおよびCSIプラグインにより、VMwareはK8sワークロードのネットワークおよびストレージサポートを提供できます。PKSを使用している場合、またはvSphere上でOSS K8sを実行している場合は、これらの2つのプラグインにすでに慣れている必要があります。NSX-TベースのCNIプラグインを使用すると、新しいK8sクラスターと作成する新しいネームスペース毎に新しい仮想スイッチが作成されます。しかし、ここには落とし穴があります。この統合のため、Project Pacificを実装および使用する場合は、クラスターでNSX-Tを使用する必要があります。クラウドネイティブストレージプラグインを使用すると、K8sの永続的なボリュームであるvSphereデータストア(VMFS, NFS, または vSAN)を利用することができます。vSANを使用する場合、ストレージポリシーベース管理(SPBM)機能をK8sストレージクラス定義に拡張できます。
  3. 認証プロキシ:K8sがvSphere SSOドメインと双方向にやり取りできるようにします。

 

f:id:t_komiya:20200118140558p:plain

各コントロールプレーンVMには、管理用とNSX Clusterトラフィック用の2つのvNICもあります。
この時点で、コンテナ―化されたアプリケーションを実行する準備が整ったvCenter サーバーとESXiホストができましたが、どうやってそれを行いますか?これは、ネイティブポッドの概念が登場するところです。Dockerのようなデフォルトのコンテナランタイムを使用する代わりに、VMwareはESXi専用のCRXと呼ばれる新しいコンテナランタイムを導入しました。そのため、ネイティブポッドの一部としてコンテナを実行すると、ネイティブポッドはVMのように見えます。これは事実になりますが、実際にはネイティブポッドを展開するたびに展開される最適化されたVMになります。


ネイティブポッドには、最適化されたvmxコンポーネントを含まれる最適化されたLinuxカーネルのCRXが含まれています。CRXはLinuxカーネルを起動し、ブートに直接ジャンプします。そのため、ネイティブポッド(最適化されたVM)は非常に高速に起動し、ESXiホスト上でコンテナをネイティブに実行することができます。ネイティブポッドもスーパーバイザークラスターに展開され、イメージの読み込みなどのシステムタスクの一部を実行します。これらのポッドは、実行するはずのタスコに基づいて行き来します。したがって、それらは長時間実行されるポッドではありません。Harbor コンテナレジストリをネイティブポッドとしてデプロイすることもできます。最後にスーパーバイザークラスターでのポッド間通信は、vanilla OSS K8sクラスターの場合、Kube-proxyの代わりに各ホストで実行される分散ロードバランサーによって有効化されます。
スーパーバイザークラスターとその上で実行されるネイティブポッドの全体像をようやくするために、VMworld EMEAから以下のスライドが紹介されると思います

f:id:t_komiya:20200118135935p:plain
ユーザーまたは開発者がスーパーバイザークラスターおよびネイティブポッドの概念を利用して、ESXiホスト上でコンテナーを直接実行できるようにvCenterサーバーおよびESXiホストに新しい機能が追加される方法を示します。
次回のブログでは、Kubernates-As-A-Service機能をお客様に提供するProject Pacificのゲストクラスター機能について紹介しようと思います。

 

ROBO/エッジ向け小規模向けvSANアプライアンス ThinkAgile VX1320/ ThinkAgile 1U 1ソケット認定ノードの紹介

 
皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は新しいvSANのアプライアンスのご紹介を行いたいと思います。
 
小規模の構成だけどHCI検討したいが、最小構成でもかなり金額が高い製品が今まで多かったと思います。中規模レベルのサーバーで最小構成でも意外と値段が高くなるケースもあります。
また、近年はエッジコンピューティングで支店レベルで分析処理などでサーバーが必要なケースがあるものの、仮想マシンの搭載する台数も少ないため、64GB程度のメモリで十分のお客様もいらっしゃるかと思います。
 
そのニーズに応えたvSANアプライアンスがこの度発表されております。
(USの発表のみで日本では未発表ですが、製品はLaunchされています)
ThinkAgile VX1320
ThinkAgile VX 1SE Certified Node
 
今回はこちらの2機種について仕様も含めてご説明したいと思います。
 
1.ThinkAgile VXシリーズのラインナップ

f:id:t_komiya:20191222160640p:plain

今回リリースされたThinkAgile VX1320は左下にあるラインナップで、主に小規模の環境に適したモデルになります。
今まではVX2000シリーズが最小機種になっていましたが、VX2000シリーズは小規模でありながら容量を大きめに構成できるモデルになっていましたが、それよりもさらに小さいモデルになります。

f:id:t_komiya:20191222161059p:plain

今回リリースされたモデルの特徴は1ソケット専用モデルです。サーバーも従来型のメインストリームThinkSystem SR630がベースではなく、ThinkSystem SR250がベースになっており、廉価版のサーバーでの構成が可能になっております。従来のモデルにおいても1ソケットを構成することは可能ですが、今回は1ソケットのみのモデルであり、また、CPUのコアも6コアおよび8コアで5種類のCPUのラインナップから選択することになります。(メモリ構成も32GB/48GB/64GBのみです)
NICについても、オンボードが1Gb NICでPCIeで10Gb NICを追加で選択可能です。
小規模構成であれば1GbのネットワークでvSANを構成することも可能ですが、中規模(8台構成)になる可能性がある場合、10Gbで初めから構成しましょう。
2.主なスペックについて

f:id:t_komiya:20191222162052p:plain

f:id:t_komiya:20191222162131p:plain

ThinkAgile VX1320および VX 1U SE 認定ノードについては、各種パーツのスペックは共通になっております。SSDおよびHDDの構成について上のイメージのようにグループ毎に構成が様々に構成できるようになっております。
また、1Gbと10Gbの混在構成については、ESXiの混在構成における仕様をあらかじめ確認しておいた方がよいと思います。
 3.ThinkAgile VX1320の構成について

f:id:t_komiya:20191222162811p:plain

ThinkAgile VX1320の構成についてですが、ディスクグループの数によって、SSDおよびHDDの構成が異なります。構成を組む場合にはこちらの図を是非参考にして頂ければと思います。特徴なのは小規模構成のモデルにも関わらず3つのディスクグループを構成できることです。
4.2ノード構成のvSANを構成する場合の注意事項

f:id:t_komiya:20191222163116p:plain

昨年のブログ(https://blog.lenovojp.com/entry/2018/04/03/120825)にも内容を記載しておりますが、再度記載しておきたいと思います。
2ノードvSAN構成時はWitnessサーバーが必要となります。そのため、Witnessサーバーを構成する際は、別のESXiのサーバーが必要になります。その際、ThinkAgile製品の保守と同様にサポート受けるためには、WitnessサーバーをインストールしているESXiもThinkAgile Advantageのサポートを受けられるシステムが必要となります。
そのためには、ThinkAgile VXで構成したサーバーが本社(もしくはデータセンター)などで必要になりますので、ご注意下さい。
 
以上、よろしくお願い致します。
 
 
 
 
 

これからのHCIはオールフラッシュ化が不可欠?~すべてのワークロードをAll Together Now!~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はハードウェアとその技術の観点からHCIのことを語ってみようと思います。

 

HCIでオールフラッシュというと、非常に高額なシステムになりそうなイメージに捉えられるかと思いますが、数年前までは確かにSSDはとても高価なものであり、とてもHCIで構成しようとすると目が飛び出るくらいの金額になってしまいました。

 

でも、今でもそんな金額感なのでしょうか?

NVMeなどは確かにまだまだ安価になっているとは言い切れませんが、SSDに関しては、実際に15Krpmや10KrpmのHDDに比べても遜色のない金額になっています。

(逆に15Krpm/10KrpmのHDDが少なくなっている?)

 

情報は古くなっていますが、インターネット上でもHDDとSSDの価格はほぼなくなってきている情報もあります。

https://www.itmedia.co.jp/news/articles/1512/09/news103.html

https://pc.watch.impress.co.jp/docs/news/1003627.html

 

上記情報からすべてSSDでオールフラッシュ構成で購入しましょうという話はあくまで価格面でのメリットしかないようにしか見えないため、オールフラッシュ化に伴ってHCIでテクノロジーも含めて覚えてみましょう!

 

1.自律型エクステントストア  

f:id:t_komiya:20191207140541p:plain

こちらはNutanix社に関する技術的な内容になります。

ストレージの容量が大きくなるにつれて1クラスタあたりの容量が肥大化してしまいます。ファイルサーバーのような書き込みが少ないワークロードでは問題化しにくいが、書き込みの多いアプリケーションなどを利用する場合、クラスタで管理するメタデータから大きくなりすぎてパフォーマンスに影響を与える可能性も多くなります。そのため、大容量化に備えAOS5.10から自律型エクステントストアということで、ホスト内でローカルのメタデータを管理することにより、ホスト上のVMに対してハイパーフォーマンスIO環境を提供することができます。

このテクノロジーを利用することにより、IOを高速化することができますが、このAESを利用するにあたりオールフラッシュの構成が必須になります。

この機能を実現するには、1ノードあたりSSDが12本を最低用意する必要があるため、現状は2Uのサーバーでのみ動作することになりますが、今後はAOSのバージョンアップにより制限が緩和される可能性があるかもしれません。

 

また、AES(Autonomous Extent Store)のパフォーマンス向上に関する詳細なデータは以下のURLをご参照ください。

https://www.n0derunner.com/2018/12/nutanix-aes-performance-by-example/

 

AESを利用できない構成でも価格メリットがありますので、1Uモデルでもオールフラッシュ化しましょう!

 

2. さらに効率良いHCI構成を組むには?

f:id:t_komiya:20191207142347p:plain

Nutanixをさらにパフォーマンスを上げるためには、ハードウェアのパワーを借りる必要があります。以前こちらのブログでもご紹介した、上図のイメージのようなテクノロジーになります。

 

詳細は以下のURLに説明しておりますので、再度記載することは致しませんが、少し内容を補足しながら説明を行いたいと思います。

blog.lenovojp.com

 

・NVMeを導入する場合は、10Gのネットワークではボトルネックになることもある!?

f:id:t_komiya:20191207143044p:plain

昨年投稿したブログにも記載がありますが、NVMeは64Kのコマンドキューでストレージを通信してデータをアクセスを行います。そのため、データローカリティなどで書き込んだデータが同容量分別ノードにレプリケーションを取られることを考えると、大量のデータがネットワーク上に流れます。そのため、従来の10Gbのネットワークではスピードが足りなくなることが考えられます。

一般的には最大28Gb/s程度のネットワークが必要とされることから、10Gbのスイッチではなく25Gbスイッチは最低でも用意して頂いた方が良いかと思われます。

アプリケーションの通信などにおいては、RDMAなどのホストのCPUをオフロードする機能も利用できるようなNICを用意しておきましょう。

 

25Gbのスイッチに関しては、10Gbに比べると高いように思われますが、ベンダーにもよりますが、現状はそれほど高価ではなくなっているようです。また10Gbとの互換性もありますので、もし書き込みが多いアプリケーションを稼働させる場合は25Gbのスイッチを購入するのも悪くないと考えます。

 

・メモリも選び方によってはワークロードのパフォーマンスを上げてくれる!?

f:id:t_komiya:20191207145643p:plain

前述でSSDやNVMeのお話をしましたが、メモリモジュールでもストレージとして利用可能なPersistent Memory(永続的メモリ)を利用することにさらに高速化することができます。SSDから見るとレイテンシだけでいうと1000の1程度になります。最新のIntel社のCPUでこちらのメモリを選択可能になっているので、Nutanixで対応になった場合は是非試し頂ければと思います。(現状は構成不可)


・CPUはワークロードごとに選択できるの!?

f:id:t_komiya:20191207150354p:plain

現状IntelのCPUは4桁の数字と最後にアルファベットがついていることがあります。

アルファベットをよく見るとNFV用、検索用、VMの収容度、メモリ容量によって選択できることがあります。

VDIやデータベースの場合はM/Lなどの型番を選択することでメモリをより多く搭載できるハードウェアを選択することもできるため、どのようなワークロードを動作させるのかは考慮した上で、CPUの選択することも必要かもしれません。

 

今までのシステムではワークロードによりノードを分けて提案することが多かったかと思います。HCIになりインフラを統合することにより管理は統合したもののワークロードの種類によってノードを分けて動作させることはしたくないかと思います。

アプリケーションのライセンスの関係ですべてのワークロードに適用できるわけではありませんが、ライセンス費用がかさむようなことのワークロードであれば、オールフラッシュですべて統合してしまうことにより、パフォーマンスをボトルネックを少なくするということも悪くない構成だと思います。

 

昨今働き方改革などで業務の効率化が検討されております。オールフラッシュなどを積極的に導入することにより、効率化UPできるようなHCIを実現してみてはいかがでしょうか。
 

よろしくお願い致します。

 

 

AWS上で実現するNutanix "Nutanix Clusters on AWS" について

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はAWS上のベアメタルサーバー上でNutanixクラスターを実現する”Nutanix Clusters on AWS”についてお話したいと思います。

 

こちらは、今年のNutanix .NEXTやNutanix .NEXT Japanの講演ではXi Clustersという名称で発表されておりましたが、今月からNutanix Clusters on AWSという名称に変更されました。

詳細は以下に記載致します。

 

1.ハイブリッドクラウドの導入は複雑

f:id:t_komiya:20191128133019p:plain

ハイブリッドクラウド環境はプライベートクラウドとパブリッククラウドをシームレスに管理します。ところが、プライベートクラウドでは仮想マシンのサイズおよびボリュームもリソースの限り自由に定義できるようになっていたが、パブリッククラウドにおいては、仮想マシンのサイズはTシャツサイズのように、メニュー化されて管理者が定義したいサイズではなかったり、またストレージについてもEBSもしくはS3などのクラウド事業者が用意しているストレージを使用する必要があり、パフォーマンスが出するのかどうか不安になるところもあります。

また、ネットワークについては、オンプレミスの場合VLANおよびVXLAN、Firewallなども用意して、セグメント化、セキュリティ対策を行うことができたが、クラウドではVPCやセキュリティグループなどでオンプレミスからネットワークをそのまま利用できないケースがあったりします。

 

.クラウド間のアプリの移動は難しい

f:id:t_komiya:20191128153117p:plain

オンプレミスで利用してアプリケーションをパブリッククラウドに移動することを考える際に、既存のアプリをそのまま持っていこうとするとどのようなことになるのか?

【運用面について】

スキルセット:新しいトラブルシューティング方法の習得、スクリプトを別途修正する必要がある

サードパーティの統合:バックアップ、DR、監視にはソフトウェアの再インストールが必要となる場合があります。

ネットワーク:ポリシーを再構築する必要があります。

【インフラストラクチャについて】

可用性:高可用性もしくはライブマイグレーションなし

ストレージ:ブロックストアの可用性は保証されていません

 

実際にオンプレミスの時にケアされていたことがクラウド移行時に手間がかかることがあり、アプリケーションによっては、パッケージアプリケーションのようにライセンスの関係でクラウド移行が簡単にできないケースがあり、オンプレミス同様の運用をそのままできないような場合が存在します。

.必要となるものは何か?

f:id:t_komiya:20191128154407p:plain

ハイブリッドクラウドに求められるもの、それは以下のようなものです。

・ライセンスの移植性、クラウドロックインなし

・パブリッククラウドアカウントへのネイティブ統合

・クラウド間のシームレスな動き

・一貫した構成とスキルセットを利用する単位るのプラットフォーム

何でもクラウドへ移行するということではなく、まずはクラウドに移行してよいのか?移行できるのか?を確認する必要があります。ライセンスコストだけでなく、可用性も満たせるのか?いくつかの要因をクリアしてクラウドへの移行ができます。

.Nutanix Clusters on AWS

f:id:t_komiya:20191128155131p:plain

ただし、パブリッククラウドでもオンプレミスと同様の環境がある場合はどうでしょうか?それであれば、制限も軽減するはずです。

それを実現しているのが、Nutanix Cluster on AWSになります。

 

Nutanix Clusters on AWSはAWS上のベアメタルのサーバー上で実行されており、オンプレミスの環境と同様にPrism Centralで管理されるAOSクラスターをAWS上で提供します

プライベート&パブリックインフラストラクチャに跨る真のハイブリッドクラウドあ来てクチャーであり、単一の画面で管理されて運用することができます。

既存のNutanixおよびAWSアカウントを利用してお客様がクラスタを管理することできます。

 

f:id:t_komiya:20191128155554p:plain

Nutanix Clusters on AWSが提供する価値とは何か?それは以下の内容となります。

プライベートからパブリックへのネイティブ拡張

 オンプレミスで動作している仮想マシンをツールを変更せずにAWSへ移行できます。

 オンプレミスと同様の運用方法でパブリッククラウドも管理できます。

 必要に応じて容量を追加することも可能です。また休止および再開することも可能です

AWSアカウントとのシームレスな統合

 既存アカウントを利用してAWSの管理を行うこともできます。

 ネットワークオーバーレイなしで複雑さを軽減し、遅延を改善します。(VPCの接続のみで対応可能、NSXなどのソフトウェアは不要)

最適なリソースの使用率

 支払いについてもそのままAWSクレジットを活用できます。

 利用しない場合は休止などを行うことにより効率的な支払いも可能になります。

 ベアメタルおよびネイティブクラウドサービス全体で変換可能なリザーブドインスタンスを利用することでコストを最適化します。

.Nutanix Clusters on AWSのユースケース

f:id:t_komiya:20191128182522p:plain

Nutanix Clusters on AWSのユースケースについてですが、様々なユースケースは存在しますが、オンプレミスとのハイブリッドクラウド連携で考えると、こちらのイメージのようなユースケースになると思われます。

・クラウドマイグレーション

・ⅮC統合

・オンデマンドキャパシティ
 

 お客様へのメリットについて

・共通のインターフェイスと確立されたワークフローを介してNutanixプライベート クラウドAWSに拡張

・既存AWSアカウント、Amazon Virtual Private Cloud(Amazon VPC)、AWS Direct Connectまたは既存のVPNを活用

・新しいスキルを必要とせずにAWSインフラストラクチャを管理

非クラウド対応アプリをAWSに移行し、クラウドネイティブアプリと並行して実行

・ピーク時にクラウドにバーストさせることにより、オンプレミスの使用率を向上

・Nutanixのデータサービスをオンプレミスからクラウド、およびクラウドから クラウドネイティブに拡張

 

f:id:t_komiya:20191128183125p:plain

Nutanix Clusters an AWSはEC2上のベアメタルサーバーで実行されます。英語になりますが、詳細はブログに記載されているので確認して頂ければと思います。

https://www.nutanix.com/blog/xi-clusters-the-rise-of-the-true-hybrid

 

最後にNutanix Clusters on AWSの強みともいえる機能を紹介したいと思います。

6.HibernateとResume(休止・再開)について

f:id:t_komiya:20191128184401p:plain

 Nutanix Clusters on AWSは例えばテスト・開発などのケースでワークロードを一時的に利用するが、開発が終わった場合にその環境を休止(Hibernate)する機能があります。Hibernateしている最中はAmazon S3上にデータを保存し、コンピュートについてはコストがかからない状態にしておきます。

f:id:t_komiya:20191128185119p:plain

Hibernateしたクラスタを再開することができます。この際、S3に保存していたデータを戻してEC2上で起動させます。その際データの損失はございません。

 

是非Nutanix Clusters on AWSも検討してみてはいかがでしょうか。

 

よろしくお願い致します。

 

 

 

Nutanixの統合バックアップソリューション Mineについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。

本日は、Nutanixの統合バックアップソリューションであるNutanix Mineについて紹介したいと思います。

Nutanix Mineについては、5月の.NEXTでソリューションの紹介をされておりますが、先月Copenhagenで開催された.NEXT Europeでは正式発表されておりました。

今回はNutanix Mineの必要となった背景やスペックなども含めて紹介します。

 

1.バックアップのペインポイント

HCIのプラットフォームを購入したけど、バックアップをどうするのか?を考えることがあると思います。もちろん、Nutanixなどにスナップショットやレプリケーションなどのデータ保護を行うソリューションはあります。

f:id:t_komiya:20191101152251p:plain実際バックアップを設定する際には、バックアップウインドウ(バックアップにかかる時間)やリカバリのSLAなどを決めて、いつのタイミングまでリカバリできて、どのくらいの時間かかるのかを考慮する必要があります。また、仮想化やアプリケーションでどのような連携をしなければならないのかを考える必要があり、ものによってはコストもかかります。

構築についても、セットアップが難しかったり、ライセンスが更新されたりして、作業が大変になったりすることがあります。

さらにソリューションとして統合されていないことがあったりするため、専門家チームが呼び出されることもあったりします。

f:id:t_komiya:20191101152823p:plain

また、従来のバックアップは非常に複雑で、バックアップの媒体がいろいろ存在しており、またセカンダリデータとしての管理がされていないことが多く、有効利用されていないことがあります。データをバックアップしたのは良いが、実際にリカバリに使おうと思ったりリストアできないというようなこともあります。実行容量に対して、バックアップのストレージはコスト的にも安く導入されるが運用がキツイくなることも多くあります。

2.セカンダリストレージの簡素化:Nutanix Mine

そこで登場したのがNutanixの統合バックアップソリューションであるNutanix Mineになります。

f:id:t_komiya:20191101153250p:plain

Nutanix Mineはセカンダリストレージを簡素化するソリューションでNutanixのPrism上からVeeamもしくはHYCUなどの対応バックアップソフトウェアであれば、バックアップ・リストアに関するオペレーションが簡素化されています。

また、Nutanixのアプライアンス上で動作するから容量などもスケールアウトするように設計になっています。

f:id:t_komiya:20191101153532p:plain

Nutanix Mineを利用することで、Nutanixだけでなく、レガシーの3Tier環境のバックアップも対応しております。バックアップ対応としては、NutanixのオブジェクトストレージであるNutanix ObjectsやS3互換のストレージが対象になっています。スケールアウト対応システムで、スケールアウト対応可能なオブジェクトストレージであれば、今後の対応も安心できると思います。

.簡素化された導入手順

f:id:t_komiya:20191101153822p:plain

まず初めに、NutanixのSizer上でサイジングを実施します。機器購入後はNutanixクラスタを稼働させます。Nutanixクラスタ上に対応ソフトウェアを導入しますが、数分でデプロイが完了します。導入後の運用について、容量不足になった場合は増設用のノードを購入することでスケールアウトも可能になりますし、保守についてもNutanixと一括に保守を受けられるような仕組みになっているようです。

.Nutanix Mineの構成について

f:id:t_komiya:20191101154254p:plain

Nutanix Mineについては上記のような構成でリリースされますが、OEMのハードウェア各社でも対応が予想されますので、詳しくは各ハードウェアベンダーにお問い合わせください。

Small, Medium, スケールアウト向けの3つタイプに分かれます。

または、Veeamのライセンスに関しては、Enterprise Plusのライセンスが同梱されるようです。

f:id:t_komiya:20191101154752p:plain

導入後の画面については、こちらのようになります。Prismの画面右上のほうにNutanix Mineのロゴが表示されるようになります。

ダッシュボードについても実行容量や実行ジョブなどの情報が表示されるようになります。

 

このようにしてNutanixのPrism上からバックアップも統合して運用することができ、単一画面からの操作が可能になります。

また、対応ハイパーバイザーとしては、ESXiおよびAHVになります。

 

Nutanixでバックアップを検討される方は是非一度ご検討下さい。

 

よろしくお願い致します。

 

 

 

セルフサービスポータルについて(その2)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は前回の記事の続編としてPrismの機能の一つである、セルフサービスポータルについて説明したいと思います。

f:id:t_komiya:20190930101304p:plain

セルフサービスポータル の管理についてお話したいと思います。

セルフサービスポータルは6つの管理機能を備えております。

・ユーザー管理

・ロール管理

・カタログ管理

・イメージ管理

・VM管理

・プロジェクト管理

それぞれコンポーネントを管理することになりますが、具体的にどのようなことを行うのかお話したいと思います

f:id:t_komiya:20190930100953p:plain

ユーザー管理

 Active Directoryからインポートされたユーザーに対して管理タスクを実行できません。ユーザーページには、SSPがユーザーを認証するディレクトリサービスのユーザーのみが一覧表示されます。ただし、ユーザー名をクリックして、ユーザーに関する詳細を表示 できます。詳細情報にはプロジェクトメンバーシップと所有するVMに関する統計と情報が 含まれます

ロール管理

SSPには更新または削除できないDevOpsという名前の組み込みのユーザーロールが 含まれています。プロジェクトメンバーがすべてのVM管理特権をSSPで使用できるようにする場合は、このロールを使用します

プロジェクトメンバーに特権のサブセットのみを持たせる場合は、ロールを作成します

カタログ管理

カタログ管理タスクには、VMを作成する権限を持つユーザーが使用できるように、VMと ディスクイメージをカタログに追加することが含まれます。セルフサービス管理者のみが カタログアイテムを作成および管理できます

f:id:t_komiya:20190930101835p:plain

イメージ管理  

ディスクイメージとISOイメージをSSPにアップロードできます。ユーザーは、VMを作成するときにカタログからイメージを選択できます

VM管理

カタログでVMテンプレートを使用可能にし、プロジェクトメンバーに既存のVMを割り 当てる必要があります。さらに、他のセルフサービスユーザーと同様に、独自のVMを作成および管理できます

インフラストラクチャVM(PrismのPrism管理者によって作成されたVM)でアクションを実行することもできるため、インフラストラクチャVMを使用する場合は注意が必要です

セルフサービス管理者であっても、そのプロジェクトのVMを作成できるようにするには、プロジェクトに自分自身を追加する必要があります

プロジェクト管理

セルフサービスが必要なチームごとにプロジェクトを作成し、プロジェクトにユーザーとグループを追加します。また、ネットワークを追加し、オプションでプロジェクトの インフラストラクチャ要件に基づいてリソース使用量のクォータを指定します

f:id:t_komiya:20190930102144p:plain

カタログへのVMの追加

カタログにVMを追加すると、SSPのすべてのプロジェクトでユーザーがVMのテンプレートを使用できるようになります

必要な権限を持つユーザーは、テンプレートからVMを作成できます

VMをカタログに追加した後、VMを削除しないでください

カタログにVMを追加するには、次の手順を実行

1.左側のナビゲーションで[VM]をクリックし、カタログに追加するVMを選択します

2.[アクション]メニューから[カタログに追加]を選択します

f:id:t_komiya:20190930102347p:plain

プロジェクトメンバーへのVMの割り当て

特定のプロジェクトのスコープ内でメンバーにVMを割り当てる。VMを割り 当てることができるプロジェクトメンバーは1人だけです

VMをプロジェクトメンバーに割り当てるには、次の手順を実行:

1.左側のナビゲーションで[VM]をクリックし、カタログに追加するVMを選択します

2.[アクション]メニューから[Ownershipの管理]を選択します

3.[プロジェクトメンバーシップ]の中で、プロジェクトを選択します

4.VMのオーナーの中で、VMを割り当てるADユーザーのユーザー名を入力します

5.[保存]をクリックします

f:id:t_komiya:20190930102524p:plain

リソースの使用量の監視について

SSPを使用して、さまざまなプロジェクト、VM、およびプロジェクトメンバーによるリソース使用量を監視できます。

さまざまなプロジェクト、VM、およびユーザーによるリソース使用量を監視するには、次の手順を実行:

左側のナビゲーションペインで[プロジェクト]をクリックし、プロジェクトテーブルの上にあるvCPU使用量の合計、メモリ使用量の合計、ストレージ使用量の合計インジケータを表示します

・インジケーターは、SSPのすべてのプロジェクトによる総リソース使用量を示します
・プロジェクトテーブルでプロジェクトごとのリソース使用量を表示します
・プロジェクトテーブルでプロジェクトの名前をクリックし、プロジェクト内のメンバーおよびVMによるリソース使用量を表示します

  • [サマリ]タブをクリックして、プロジェクトの統計情報、リソース割り当てごとの上位5ユーザー、およびリソース割り当てごとの上位5つのVMを表示します
  • [使用状況]タブをクリックして、vCPUカウント、メモリ使用量(バイト単位)、ストレージ使用量をバイト単位で表示します
  • [VM]タブをクリックして、プロジェクト内のVMによるリソース消費に関する情報を表示します
  • [ユーザー]タブをクリックして、プロジェクトメンバーによるリソース消費に関する情報を表示します

f:id:t_komiya:20190930102909p:plain

セルフサービスポータルの統合について

・Prism Central Administrator

エンドユーザーがセルフサービス方式でインフラストラクチャリソースを使用できるようにするセルフサービスポータルは、以前はPrism Elementを介してクラスターでホストされていました。これで、セルフサービスポータルがPrism Centralを通じて実装され、Prism Central Webコンソールユーザーインターフェイスからセルフサービスポータルの全機能を管理できます。

・Self-Service Administrator

セルフサービス管理者は次のタスクを実行:

・セルフサービスを必要とする各チームのプロジェクトを作成し、Active Directoryユーザーとグループをプロジェクトに追加します 
・プロジェクトメンバーのロールを構成します
・VMテンプレートとイメージをカタログに公開します 
・さまざまなプロジェクトとそのVMおよびメンバーによるリソース使用量を監視し、必要に応じてリソースクォータを調整します

Prism Central管理者はこれらのタスクを実行することもできますが、通常はセルフサービス管理者に委任されます

・Project User

これらは、セルフサービス管理者によってプロジェクトに割り当てられたユーザーです。セルフサービス管理者が許可するアクションを実行できます。パーミッションは、プロジェクト内のユーザーとグループに割り当てられたロールによって決まります。プロジェクトユーザーがログインすると、カスタムセルフサービスGUIインターフェイスが表示され、ロールのアクセス許可で許可されているもののみが表示されます。プロジェクトユーザーは、必要なものだけを作成および管理します。

 

注意事項:

Prism Centralから直接カスタマーサポートケースを作成および監視できるようになりました。 Prismを通じてサポートケースを作成する場合、次の要件と制限が適用されます。

・この機能はPrism Centralでのみサポートされ、Prism Elementでは利用できません
・Prism Centralでサポートポータル接続(インターネットアクセス)を有効にする必要があります
・少なくとも1つのクラスターをPrism Centralに登録する必要があります
・自動ログ収集とヘルスチェックは、ターゲットクラスターがインターネットに接続されている場合のみのオプションです

 

以上、よろしくお願い致します。

 

セルフサービスポータルについて(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はPrismの機能の一つである、セルフサービスポータルについて説明したいと思います。

 

まずは、セルフサービス ポータルが何をするのかを説明したいと思います。

f:id:t_komiya:20190929230035p:plain

Prismセルフサービスポータル(SSP)により、企業内のITインフラストラクチャの利用者 (開発、テスト、DevOpsなどの個々のユーザーまたはチーム)が、日常業務でITに関与する ことなくセルフサービス方式で仮想マシンをプロビジョニングおよび管理できます。

SSPはAOSの一部であり、AHVが必要であり、単一のAHVクラスターによって提供されるリソースを使用できます。SSPには個別のユーザーインターフェイスがあり、単一のActive Directory(AD)ディレクトリサービスに接続することにより、管理者とユーザーを認証 します。Prism管理者は、セルフサービスポータルを管理する権限をセルフサービス管理者と 呼ばれる1人またはActive Directoryユーザーに委任することができます。SSPでは、セルフ サービス管理者がエンドユーザー向けのセルフサービスプロジェクトを作成および管理し、 ユーザー権限、リソース使用制限、VMテンプレートとディスクイメージのカタログなどの セルフサービスのさまざまな側面を管理します。

セルフサービス管理者によってプロジェクトに追加されたActive Directoryユーザーは、SSPにログオンし、必要なもの(仮想マシン)のみを作成および管理します。 SSPは、プロジェクト、VM、およびプロジェクトメンバーごとのインフラストラクチャ使用統計もレポートします。SSP管理者は、どのプロジェクト、VM、およびユーザーが最もリソースを消費し、どのプロジェクトがより少ないリソースを必要とするかなどの洞察を得ることができます。SSPは、Internet Explorer 11、Safari、Mozilla Firefox、およびGoogle Chromeでサポートされています。

f:id:t_komiya:20190929230220p:plain

セルフサービスの管理者としてログインについて

セルフサービス管理者として識別されている場合は、Prism管理者がSSPの初期構成を完了した後、管理者としてSSPにログオンできます。

SSPにログオンするには、次の手順を実行

1.サポートされているブラウザーのウィンドウで、SSP URLを入力します。

https://cvm_ip_address:9440/ssp/

cvm_ip_addressをコントローラーVM IPアドレスに置き換えます。ホストに仮想IPアドレスを割り当てている場合は、コントローラーVM IPアドレスの代わりに仮想IPアドレスを使用できます。

2.ADユーザー名とパスワードを使用してSSPにログオンします。

f:id:t_komiya:20190929230433p:plain

初期設定について

初期構成の実行(Prism管理者タスク)

初期構成時にPrismで構成されたADからユーザーとグループをインポートします。PrismでADが構成されていない場合は、初期構成ページから新しいAD接続を作成する必要があります。

ADユーザーまたはグループを指定して、SSPを管理します。

初期構成を実行するには、次の手順を実行

1.内部管理者の資格情報を使用してSSPにログオンします。

2.次のいずれかを実行します。

・PrismでAD接続が構成されている場合、ページの[ディレクトリサービスの選択]の セクションのリストから1つを選択します。利用するAD接続がPrismで構成されておらず、SSP用に 作成する場合は、Prism Web コンソールで作成し、SSPの初期構成画面に戻り、リストからADを選択します。PrismでAD接続が構成されていない場合にのみ、SSPの初期構成画面からAD接続を作成可能。


・PrismでAD接続が設定されていない場合は、ページの[ディレクトリサービスの設定]セクションで 名前、ドメイン、ディレクトリURL、および接続タイプを指定します。

3.[資格情報]セクションの[ユーザー名とパスワード]に、ADのクエリに使用できるADユーザーアカウントの資格情報を入力。

4.[次へ]をクリック。

5.[Prism Self Service Adminの割り当て]で、SSPを管理する必要があるADユーザーまたはグループの 名前を入力。

6.[保存]をクリック。

f:id:t_komiya:20190929225808p:plain

セルフサービスポータルのコンポーネントについて

 ・プロジェクト

SSPのプロジェクトをリスト化します。プロジェクトは、エンジニアリングプロジェクトで共同作業するエンジニアのチームなど、共通要件の内容または共通の構造と機能を持つADユーザーのセットを定義します。プロジェクトは、メンバー、メンバーが使用できるネットワーク、およびオプションでインフラストラクチャリソースの使用制限に関連付けるロールも指定します。ユーザーを プロジェクトに追加して、SSPを使用するようにユーザーを招待します。

・ロール

組み込みの役割であるDevOpsを含む、作成されたすべての役割を一覧表示します。DevOpsロール には、VM、仮想NIC、および仮想ディスクの作成、表示、更新、削除、VMのクローン作成、VMの 電源オンおよび電源オフ操作を実行する権限があります。

[ロール]ページで、ロールを作成および管理できます。ロールは、VM操作を実行するための一連の 権限を定義します。各プロジェクトで1つの役割が指定され、プロジェクト内のすべてのユーザーに適用されます。

SSPには、内部管理者のロール(ユーザー名admin)と、初期構成中にセルフサービス管理者に割り当てられるセルフサービス管理者の役割が含まれます。これらのロールは、[ロール]ページには表示されません。

・カタログ

セルフサービスユーザーが利用できるようにするVMテンプレートとイメージを一覧表示します。

カタログ内のアイテムは、ユーザーがVMを作成するときに選択できます。

f:id:t_komiya:20190929230819p:plain

・VM

SSPがPrismからインポートしたVMと、SSPユーザーが作成したVMの両方がクラスターで実行されている一覧を表示します。 [VM]ページでは、プロジェクト用のVMの作成、VMの起動または停止、VM所有権の変更など、VM関連のさまざまなタスクを実行できます。ユーザーがセルフサービス管理者であっても、そのプロジェクトのVMを作成できるようにするには、ユーザーはプロジェクトに属している必要があります。

プロジェクトメンバーがVMを使用できるようにするには、VMの所有権をプロジェクトメンバーに変更 するか、VMをテンプレート形式でカタログに追加して、ユーザーがVMを作成できるようにします。

・ユーザー

SSPのプロジェクトに追加されたADユーザーをリスト化します。このページには、内部管理者ユーザーとセルフサービス管理者も一覧表示されます。

・イメージ

SSPにアップロードするディスクおよびISOイメージをリストします。

カタログにイメージを追加できます。

 

次回はセルフサービスの管理とセルフサービスポータルの統合についてお話したいと思います。

 

以上、よろしくお願い致します。

 

エッジコンピューティングについて(その2)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。今回も前回の続きでエッジコンピューティングの話をしたいと思います。

 

前回はエッジコンピューティングの必要性についてお話しましたが、今回はエッジコンピューティングの利用シーンについてお話したいと思います。

 

・エッジサイトの課題

f:id:t_komiya:20190917103032p:plain

アンケートに投票された何百人もの顧客が、エッジ環境における同じ課題と要件に言及しました。

エッジサーバーは、過酷な環境に耐えることができ、安全であり、最小限のメンテナンスが必要です。

有線ネットワークなしで動作できる必要があります。そのため、ワイヤレス接続やセルラー接続を含める必要があります。

仮想化に対応し、限られたスペースに収まるほど小さくする必要があります。

従来のエッジコンピューティングのオプション

f:id:t_komiya:20190917103203p:plain

IoTゲートウェイやPC、またはより大きなラックサーバーやタワーサーバーなど、現在利用可能なデバイスは、エッジ環境での使用は可能ですが、常にエッジ環境のニーズを満たしているとは限りません。

多くの場合、IoTゲートウェイとPCには必要なメモリまたはCPU能力がありませんが、ラックおよびタワーサーバーは大きすぎてコストがかかりすぎる場合があります。

既存のオプションが環境の要件を満たしていない場合、より特殊なオプションが必要になる場合があります。

・エッジサーバーの選択

f:id:t_komiya:20190917103336p:plain

エッジサーバーはローカルIoTネットワークを他のネットワークまたはインターネットに接続します。

このスライドは、レノボのネットワークのエッジ側で使用できるデバイスを示しています。

従来のラックサーバーは、エッジサーバーとして使用される可能性はありませんが、使用される可能性はあります。

タワーサーバーは、ほこり、振動、腐食性物質が存在しない環境でエッジサーバーとして使用される可能性が高くなります。

左側のPCなどの小さなPCは頑丈ですが、必要なCPUパワーやメモリおよびストレージ容量がない場合があります。

IoTエッジサーバーは、センサーやその他のIoTデバイスをネットワークに接続する特殊なデバイスです。また、通常はデータの前処理を実行する場合があります。

コンパクトエッジサーバーが最適な場所

f:id:t_komiya:20190917103545p:plain

コンパクトエッジサーバーは、高価なフル機能のサーバーとIoTゲートウェイおよびPCの間のギャップを埋めます。

両方の長所を実装していることに注意してください。過酷な環境に耐えるように堅牢化でき、小さいながらもデータの前処理を実行するのに十分なコンピュート能力を備えています。さまざまなクラスの製品の機能を見てみましょう。

エッジサーバーの特徴

f:id:t_komiya:20190917103716p:plain

この図は、さまざまなデバイスタイプがIoTデバイスの全体的なポートフォリオに適合する場所を示しています。

中央に隙間があることに注意してください。

パフォーマンスは中程度ですが、過酷な環境に展開するのに十分な堅牢性を備えたデバイスがそこに行きます。

このスペースは、今後IT企業にとって非常に重要になります。

注:PLCはプログラマブルロジックコントローラーであり、ローエンドコンピューターであり、高耐久化されており、産業または製造プロセスの制御に適合しています。

例えば組立ラインまたはロボットの制御が含まれます。

・コンパクトエッジサーバーの特徴

f:id:t_komiya:20190917103953p:plain

コンパクトなエッジサーバーがこのギャップを埋めます。

垂直(堅牢性)方向にはかなり大きな範囲があり、これは潜在的に小さなカテゴリに分類できることに注意してください。

・コンパクトエッジサーバーのカテゴリ

f:id:t_komiya:20190917104059p:plain

この図は、エッジサーバーの3つの下位区分を示しています。

すべて同等のパフォーマンスとデータストレージ容量を提供しますが、異なる環境に適しています。

一番下のバリューエッジサーバーは過酷な環境には適していないため、オフィススペースや比較的クリーンな産業環境で使用される可能性があります。

中央のメインストリームエッジサーバーは、熱、振動、ほこり、およびわずかに腐食性の環境に耐えることができます。産業環境で使用できます。

上部には完全に頑丈なエッジサーバーがあり、熱、振動、ほこりが極端な環境での展開に適しています。

これらは、軍隊によって展開されたエッジサーバーと堅牢性が同等であることに注意してください。

また、カテゴリはやや右に傾いていることに注意してください。堅牢性は実装に費用がかかります。

f:id:t_komiya:20190917104223p:plain

世界は急速に変化しており、IT業界も変化しています。

この変更の基本的なドライバーは、手頃な価格、アクセシビリティ、および機能です。

手頃な価格であるため、製造業者はインテリジェントなデバイスを大規模なあらゆる物理的環境に近づけることができます。

アクセシビリティは、ほぼすべての場所で利用可能なインターネットおよびクラウドサービスによって作成されます。つまり、すべてを接続できます。

また、ネットワークの速度と帯域幅(5Gを考える)、および大量のデータを取得してそれを理解する能力(AIを考える)の両方として機能が存在します。

 

レノボはこれらをサポートするエッジコンピューティングプラットフォームとしてThinkSystem SE350を発表しました。

ThinkSystem SE350の紹介を少しだけしたいと思います。

f:id:t_komiya:20190917111137p:plain

ThinkSystem SE350はエッジ コンピューティングの要件に合わせて設計 された専用のサーバーです

スモールフォームファクター

  • 高さ:1.75インチ(40mm)
  • 幅:8.1インチ(215mm)
  • 奥行き:14.9インチ(376mm)

通常のデータセンターのサーバーでは収容 できない場所で利用します

f:id:t_komiya:20190917111228p:plain

過酷な環境に対応可能です。

データセンターではない環境動作するように設計されており、以下をサポートします:

  • 0-55
  • 最大95%の湿度
  • ほこり
  • 衝撃
  • 振動

f:id:t_komiya:20190917111345p:plain

安全性の高いソリューションが提供可能です。

ThinkSystem SE350には、サイバー セキュリティ機能と物理的改ざん防止機能の両方が含まれています。 誰かがサーバーを開こうとすると、ストレージ暗号化キー 無効になるため、誰も許可なくデータ アクセスできません

f:id:t_komiya:20190917111451p:plain

複数の接続オプションが提供可能です。

どこにでも展開できるように設計されており、複数の接続オプションを提供します

  • 有線

   10 / 100MB / 1GbE、1GbE SFP 10GbE SFP +、10GBase-T 

  • 無線

   Wi-Fi

   LTE

f:id:t_komiya:20190917111640p:plain

シンプルな管理を実現します

SE350はLenovoのXClarityで管理されているため、他のThinkSystemサーバーで使用されているの同じ機能と利点がすべてThinkSystem SE350でも利用できます

f:id:t_komiya:20190917111755p:plain

エッジコンピューティングは高価になる可能性があります なぜなら導入と管理が困難だからです ThinkSystem SE350 Edgeサーバーにより Edgeコンピューティングがより簡単になり、費用対効果 高まります

ThinkSystem SE350はEdge設計された目的です

  • 小さなスペースに収まるコンパクトサイズ
  • 過酷な環境に対応する堅牢性
  • 複数の接続オプション
  • 物理的およびサイバーセキュリティ
  • Lenovo XClarityによる管理の簡素化


以上がエッジコンピューティングの説明となります。

 

よろしくお願い致します。

 

 

エッジコンピューティングについて(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はエッジコンピューティングについてご説明したいと思います。

よく聞きにするIoT(Internet of Things)で登場する内容で、クラウドおよびデータセンターではなく、エッジ(ユーザーもしくはユーザーの近くの端末)で分散配置することで、通信の遅延を抑制することがメリットとされています。

では実際に、どのような内容なのかを2編に分けてご紹介したいと思います。

 

f:id:t_komiya:20190916213347p:plain

モノのインターネット(IoT)とは、インターネットに接続されている世界中の数十億の物理デバイスを指します。これらのデバイスには、データの収集と共有のみを行うものと、インターネット上で制御できるものがあります。

プロセッサとワイヤレスネットワークはどちらも非常に安価になり、この低コストにより、インターネットに接続されたさまざまなデバイスを製造できるようになりました。これらは、航空機や自動運転車に搭載可能な錠剤サイズのカメラです。

プロセッサは、以前のダム端末にインテリジェンスを追加し、人間の介入なしにリアルタイムでデータを通信できるようにします。これにより、デジタルと物理の世界が効果的に融合します。

f:id:t_komiya:20190916213951p:plain

コンシューマ向けIoTデバイスは、特にAmazonやGoogleなどの有名企業に採用されて以来、より人気が高まっています。

・スマートホーム

f:id:t_komiya:20190916214055p:plain

家庭用のIoTデバイスの例をこちらのイメージに示します。 GoogleやAmazonなどのスマートアシスタントは、大量のデータをキャプチャして処理します。サーモスタットは在宅者のパターンを学習し、インターネットで制御できます。他のデバイスも、よりインテリジェントになる方法で動作します。

・ウェアラブル

f:id:t_komiya:20190916214200p:plain

コンシューマの領域では、よりインテリジェントなデバイスも見られます。カメラは顔を認識し、その情報に基づいて行動します。スマートウォッチは、着用者の活動を追跡し、健康とフィットネスの提案を行います。拡張現実と仮想現実の眼鏡は、空間での着用者の方向を追跡し、それに基づいて行動を起こします。

・スマートカー

f:id:t_komiya:20190916214309p:plain

自動車の世界では、スマートデバイスは駐車および衝突の回避、慣れていない道路の移動(ナビゲーション)に役立ちます。

リアルタイム更新により自動車のトラフィックを追跡し、代替ルートを提案します。

自動運転車は、業界の最先端の取り組みです

障害物を避けながら車を路上で運転させるために必要なセンサーの数を考える必要があります。

意思決定は非常に迅速に行われる必要があるため、データをある程度離れた集中管理されているポイントに送信して処理した後、車に送り返すことはできません。

ローカルで処理する必要があります。

車外で処理を行う重要なデータ(車両運行管理など)のみを他の場所に送信する必要があります。IoTネットワークのエッジは車内になります。

f:id:t_komiya:20190916214545p:plain

ビジネスの世界では、IoTデバイスは効率の改善に役立ちます。

・スマートリテール

f:id:t_komiya:20190916214718p:plain

店舗のセンサーは、製品に対する顧客の関心を追跡し、顧客が最も時間を費やしている場所を確認し、チェックアウトプロセスを支援できます。商品を追跡でき、在庫が在庫状況の変化に応じて管理されます。特定のアイテムが販売されている場合など、価格はリアルタイムで調整できます。

・スマートシティ/キャンパス

f:id:t_komiya:20190916214820p:plain

IoTデバイスを使用して、キャンパス、町、都市などのより大きなスペースの設計と運用を最適化できます。

交通量のビデオ分析は、市民の移動時間を最適化し、混雑を制限し、渋滞を減らすために、信号のタイミングに取り込むことができます。

オープンパーキングスポットのリアルタイム情報は、コマンドセンターおよび都市の訪問者に提供され、緊急時の出入りを制御できます。

設備および利用者の使用状況データを建物の制御システムと組み合わせると、エネルギー消費を削減できます。

モーションセンサーと赤外線センサーは、動きと存在を監視し、エネルギーを削減し、公共の安全を維持できます。ビデオフィードはリアルタイムで犯罪を分析し、当局が犯罪者を見つけるのに役立ちます。

関心のある地点で汚染レベルを監視すると、水質の問題や汚染物質を早期に検出して、環境と水の供給への影響を減らすことができます。

大気汚染データを分析することにより、交通と産業を調整して、高度に汚染された地域の有害レベルを削減し、市民に外部活動を制限するよう通知することができます。 センサーが組み込まれたスマートメーターは、水とガスの消費量を測定し、漏れを検出できます。

住宅および産業施設でのエネルギーのピーク時消費の追跡と管理により、グリッドの信頼性を確保できます。

屋内ナビゲーションは、ユーザーが関心のある場所、最適なルート、非常口を見つけるのに役立ちます。

コネクテッドカーのい追跡により、大規模車両の管理を改善し、コストを削減し、資産の使用を最適化し、問題が発生した場合に規定のサービスを提供し、損失を防ぐことができます。

ライブビデオストリーム、ライブバストラッキング、WiFiサービスの有効化により、公共交通機関のユーザーエクスペリエンスが向上します。

・スマートマニュファクチュアリング

f:id:t_komiya:20190916214946p:plain

センサーは、機械または機械部品が障害に近づいていることを判断でき、障害が発生する前に修理措置を講じることができます。

カメラは、マシンビジョンとAIソフトウェアと組み合わせて、製造された部品を検査し、欠陥のある部品をリジェクトできます。

コンポーネントは製造プロセスで使用されるため、追跡され、新しい在庫を注文できます。

製造機械自体(多くの場合ロボット)は、適切なソフトウェアによって監視および制御できます。

たとえば、工具が磨耗すると、製造された部品が許容範囲内に収まるように機械を調整できます。

・IoTのアーキテクチャ

f:id:t_komiya:20190916213232p:plain

この新しい環境のアーキテクチャをイメージに示します。

特にエッジコンピューティングが配置されている場所(センサーと他のIoTデバイス、およびコアITインフラストラクチャの間)に注意してください。

エッジのデバイスはデータを収集し、初期処理を実行して、結果をコア/クラウドに転送します。 

・なぜエッジコンピューティングなのか?

f:id:t_komiya:20190916215144p:plain

エッジでのコンピューティングが必要な理由をいくつか示します。

センサーが非常に多いため、ネットワーク帯域幅の制限と処理の制限のために、データをリアルタイムでコアに送信できません。

多くの場合、リアルタイムでの制御が必要であり、常に利用可能である必要があるため、処理はデータが生成される場所の近くで実行する必要があります。

場合によっては、規制によりデータの送信先が制限され、暗号化が必要になり、レイテンシが増える可能性があります。

 

続きはその2でお伝えいたします。

 

以上、よろしくお願い致します。