LTN Blog 〜 Lenovo Technology Network 〜

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

これからの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でお伝えいたします。

 

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

Nutanix Calm について【続編】

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanix Calmの記事について投稿したいと思います。

以前にもCalmの内容は投稿しておりますが、説明だけが多くどのような画面なのかがわからない方もいらっしゃいますので、一年ぶりに画面イメージも含めてもう少しわかりやすい内容でお伝えしたいと思います。

以前投稿した記事についてはこちらになります。参考程度に見て頂ければと思います。

 

ハイブリッドクラウド環境で必要になるアプリケーションのライフサイクル管理[第二弾]~Nutanix Calmの紹介~ - LTN Blog 〜 Lenovo Technology Network 〜

 

1.Calmを利用する目的

Calm(Cloud Application Lifecycle Management)はアプリケーションに特化した自動化ソリューションです。アプリケーションのデプロイを自動化したり、Self Service Portalでユーザ管理を行うことで、ユーザ専用のダッシュボードを用意して、インフラ管理者・アプリケーションの管理者向けの利用しやすいインタフェースを提供します。

また、ハイブリッドクラウド環境などでアプリケーションを利用する場合も、それぞれのクラウドインフラを意識することがなく導入、管理ができます。

また、最近は利用状況やコストなども把握(Xi Beamとの連携)も行いながら、最適なクラウド環境にアプリケーションを移行することも可能になっています。

f:id:t_komiya:20190908105059p:plain

2.Calmの機能的な要素について

f:id:t_komiya:20190908104356p:plain

f:id:t_komiya:20190908105429p:plain

Calmを利用する際に覚えておく単語があります。

Blueprints:アプリケーションのテンプレートです。こちらの中にアプリケーションの構成します。例えばある業務アプリケーションがあれば、Webサーバー・DBサーバー・Proxyサーバーを構成をしますが、この際Webサーバーと記載する前にDBサーバーが起動していないとアプリケーションがデータを検索できない状況になったりします。そのような状況を防ぐために、アプリケーションの起動順序や依存関係を定義するために必要になります。 

セルフサービス:Calmでアプリケーションを定義する際に、どのユーザーでどのような権限で利用するのかも定義する必要があります。その際にPrism Centralでサポートされているセルフサービスの機能を利用します。こちらを利用することで、アプリケーションにおける権限付けができて、必要なユーザーには参照させないことができます。

Marketplace:Calmを利用する際に、アプリケーションをお客様側ですべて用意しなければならないわけではありません。クラウドネイティブなアプリケーションやハードウェアメーカーのリリースしているアプリケーションはMarketplaceと呼ばれるアプリケーションがアップロードされているサイトからダウンロードが可能です。

また、他の人が作成したBlueprintsも共有(Githubなどにもあります)されておりますので、もしBlueprintsの作成方法がわからない場合は、参考にするのも良いかと思います。

3.Blueprintsについて

f:id:t_komiya:20190908110617p:plain

Blueprintsの中でアプリケーションに関する要素を定義していく訳ですが、アプリケーションは主に仮想マシンやその仮想マシンの構成やネットワークのベースとなる要素とそのインフラに必要な要件のセキュリティ、接続性、依存関係、オペレーションなどが含まれます。

f:id:t_komiya:20190908110859p:plain

それぞれが設定ファイルなどではなく、GUIなどで視覚された上で管理できるため、作成した管理者のみで俗人化された管理にはならないようにすることも目的になります。

f:id:t_komiya:20190908110926p:plain

アプリケーションを定義する際に、アプリケーションに必要な要件があります。例えば、ロードバランサ(NGINX)などのインフラに関する部分に定義も簡単に行うことができます。 Blueprints上に定義して、パラメータを入れる画面が右側に表示されます。

4.Calmのサービス

f:id:t_komiya:20190908112008p:plain

Calmのblueprintsの中でアプリケーションを定義する際に、どのようなパラメータで定義するのか行う必要があります。

f:id:t_komiya:20190908112311p:plain
Calmにおいては仮想マシン・パッケージ・サービスを定義できます。

仮想マシンについては、仮想マシンの名称、OSイメージ、リソース(CPU, コア, メモリ, ディスク容量),ネットワークなどの情報を定義します。

パッケージ、サービスでは、インストールスクリプトや各種カスタマイズの設定情報も定義できます。

f:id:t_komiya:20190908113842p:plainインフラの定義できる画面がこちらになります。各種変数を定義できる項目が右側に表示されます。

f:id:t_komiya:20190908114025p:plain

パッケージに関する説明ですが、インストール用にスクリプトを埋め込むことができます。ここでサポートされているのは、BashやPowershellになります。

f:id:t_komiya:20190908114307p:plain

パッケージを定義する際に、パラメータ・マクロ・依存関係の話をしたいと思います。

アプリケーションを定義する際に、VMなどの名称を定義しますが、名称には一意性を持たせる必要があります。

f:id:t_komiya:20190908114533p:plain

マクロ定義するときには、Bashなどを利用することができるお話をしましたが、パッケージのバージョンによって動作を判定させたい場合などはイメージのような条件を定義します。

f:id:t_komiya:20190908114858p:plain

またパスワードなどを要求されるものについても、RUN TIME で変数を定義できます。

f:id:t_komiya:20190908115531p:plain

依存関係のパートになります。こちらでは、DBのインスタンスが立ち上げあってからアプリケーションを立ち上げるように条件文がつけられますが、矢印などの視覚化わかるような表示がされていることがわかります。これらはスクリプト内で定義することも可能です。

f:id:t_komiya:20190908120408p:plain

最終的にアプリケーションをBlueprints内で定義し終えたら、ローンチ(起動)をするとアプリケーションが作成できます。これを利用して、複数のコンポーネントで構成されているアプリケーションを管理を行うことができるようになります。

f:id:t_komiya:20190908120649p:plain

また、Calmについてはクラウドにも対応しております。

例えば、WebサーバーがAWSに配置されており、DBがオンプレミスに配置されているシステムについては、各種仮想マシンのアイコンなどが、クラウド・オンプレミスであることがわかるようにすることができます。

 

是非Calmを利用してハイブリッド環境におけるアプリケーションの管理を行うことで、運用を簡素化できるようにしましょう。

 

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

 

 

SAP HANA on Nutanixのベストプラクティスについて

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は以前にもお話したSAP HANA on Nutanixに関するベストプラクティスについてお話したいと思います。

こちらの内容についてですが、ちょうど一年前にNutanixのAHVにおいて、SAP HANAでのAHV認定がちょうど発表された時期だったと思います。

 

Nutanix Enterprise Cloud OSのハイパーコンバージェンスベース・ソリューション、SAP HANA®認証を取得 | Nutanix

 

昨年のNutanix .NEXT TokyoでのセッションにてSAP HANA on Nutanixの話をさせて頂きましたが、当時はまだ製品リリース間もない頃で、必要なテクノロジーの話をさせて頂きました。

 

ついに出たミッションクリティカル向けのNutanixモデル(ThinkAgile HX for SAP HANA)~ThinkAgile HX7820/HX7821のご紹介~ - LTN Blog 〜 Lenovo Technology Network 〜

 

一年ほど経過現在では、HX7820の導入事例もいくつで出てきており、また一部のお客様ではSAP HANA on Nutanixの案件も出てきております。

そこで今回は、SAP HANA on Nutanix に関するポイントとなる点をお話したいと思います。

 

1.CPUに関するベストプラクティス

f:id:t_komiya:20190831203207p:plain

SAP HANA で認定を取るためにはパフォーマンス(SAP値)が出せるようなスペックでなければいけません。

そのため、選択CPUについても現状はSkylake世代(Cascade Lake世代の認定はまだとられておりません)のCPUになっておりますが、SkyLake世代においても、PlatinumのCPUもしくはGoldシリーズ以上が必要になります。加えて最低要件として8コア以上のCPUが必須になります。

NutanixのおいてはCVMがCPUのオーバーヘッドになることから、SAP HANAを動作させるノードにおいては、必ず1CPUはCVM用にリソースを取られることになります。(HANA以外のアプリケーションはCVMと同一CPUで動作させても問題ありません)

f:id:t_komiya:20190831203804p:plain

SAP HANAはインメモリデータベースということもあり、仮想マシン起動時に仮想マシンのメモリ上にデータベースのデータをロードを行います。数百GBもしくは1TBレベルのメモリを必要としますので、1CPUのメモリ領域では収まらないこともありますので、CPU間でメモリ利用できるように共有できるようなアーキテクチャ(NUMA)を利用して、大容量のインメモリデータベースを形成します。

f:id:t_komiya:20190831203033p:plain

例えば、小さなSAP HANAのデータベースがホスト内の3台存在する場合について、このようになります。

768GB以下の容量で起動可能なレベルであれば、1CPUのメモリ空間をそのまま利用できますので、各SAP HANA VMがそのまま固定して動作します。NUMAノードのすべてのCPUのリソースを効率良く活用できるようになります。

f:id:t_komiya:20190831204930p:plain

今度は2つのSAP HANA VMが存在するケースで1つのSAP HANA VMが大きくメモリ領域を確保してしまうケースはこのように最大1.5TBまで確保するVMと768GBまでしか確保できないSAP HANA VMが存在するような形になります。

f:id:t_komiya:20190831205317p:plain

次に1つの巨大VMが3つのCPU分のメモリ領域を利用した場合に関してのイメージです。この場合は3つのCPU(NUMAノード)が固定で利用されます。

このように、CPUとメモリ領域を把握した上での運用がSAP HANAに関しては必要になってきます。

2.メモリに関するベストプラクティス

f:id:t_komiya:20190831205623p:plain

メモリに関する注意事項についてですが、インメモリデータベースということもあり、メモリのパフォーマンスは同一である必要があります。選択するCPUにより、メモリのスピード(周波数)が異なります。必ずメモリのスピードは合わせるようにして下さい。また、メモリオーバーコミットは許可されておりません。

Cascade LakeシリーズのCPUについては、CPUの種類によってメモリ容量が異なります。CPUの型番の末尾に「M」もしくは「L」のタイプのものを選択するようにして下さい。

3.ディスクに関するベストプラクティス

f:id:t_komiya:20190831210355p:plain

ディスク(ストレージ)部分については、トランザクションを即座に処理できるようなデバイスが求められております。

通常はオールフラッシュは必須ですが、インメモリデータベースのトランザクションのため、早いことに越したことはありません。ThinkAgile HX for SAP HANAのアプライアンスに関しては、デフォルトでNVMeの利用を推奨されております。

f:id:t_komiya:20190831211132p:plain

ディスクに関する細かな仕様をこちらに記載します。

SSD部分に関してはは8本以上が必須になります。また、SAP HANA DBのメモリサイズの2.5倍の容量が最小ディスクサイズになります。

サイジングする際はReplication Factorのオーバーヘッドも考慮したサイジングが必要になります。

4.ネットワークに関するベストプラクティス

f:id:t_komiya:20190831211828p:plain

ネットワークについてですが、SAP HANA環境では10GbE以上が推奨となっております。10GbE以上のスループットがあれば、速い分にはいくらでも構いませんが、SAP HANA on Nutanixにおいては、データをネットワーク経由でアクセスする際に、CPUにおけるオーバーヘッドを少なくするために、RDMAの技術を利用することが推奨とされております。この場合、SAP HANAを構成するノードはすべてRDMA対応のNICで構成されていることが前提であり、非RDMAノードとの混在は許可されておりません。

RDMAはデフォルトでCVMのeth3のインタフェースにデプロイされます。

5.仮想マシンのデザインに関するベストプラクティス

f:id:t_komiya:20190831212701p:plain

f:id:t_komiya:20190831213010p:plain

仮想マシンのデザインについては、先ほどお話したNUMAの領域に準拠する必要があります。それ以外の内容についてはイメージに記載してあり通りになります。
落とし穴として考慮しなければいけないところは省電力状態の内容になります。
6.運用に関するベストプラクティス

f:id:t_komiya:20190831213233p:plain

運用に関しては、注意すべき点はやはりAOSのバージョンです。本番環境にSTSのバージョンを利用することは基本的に推奨されておりません。LTSのバージョンで運用するようにして下さい。

詳細はCertified and Supported SAP HANA Hardware Directoryをご参照ください。

7.可用性・バックアップに関するベストプラクティス

f:id:t_komiya:20190831213539p:plain

可用性およびバックアップに関する内容ですが、N+1の考慮は当然のお話として対応しなければいけませんが、4ノードスタートで十分なリソースで運用することをお薦めします。

また、データベースのレプリケーション機能は利用するようにして下さい。NutanixのDRソリューションは現状未サポートになっております。
バックアップについては現状3rdパーティのバックアップソフトウェアを推奨しております。対応しているソフトウェアとしては、Veeam,HYCUなどがあります。

また、バックアップしたデータについては、必ずリストアのテストを行うようにして下さい。バックアップしたデータがリストアできないケースもありますので、非常事態に備えることも必要です。

 

以上、SAP HANA on Nutanixするときには一度参考にして頂ければと思います。

 

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

 

 

Nutanix Flowのユースケースに関して

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はNutanixのFlowに関しての内容をお話したいと思います。Nutanix Flowについては約1年前にもブログで内容を記載しておりますが、少し内容が古いため新しい内容でお伝えしたいと思います。

過去に掲載したブログは以下のURLになります。

Nutanix FLOWについて【第二弾】 - LTN Blog 〜 Lenovo Technology Network 〜

イメージについては、Nutanix社の資料を利用させて頂いております。

 

一般的なFlowのユースではどのようなパターンで利用されるのかを以下のイメージに示しております。それぞれのケースで簡単にお話したいと思います。

f:id:t_komiya:20190824183815p:plain

 

1.インフラ環境を隔離

f:id:t_komiya:20190824220622p:plain

Nutanix Flowは、高度なネットワークおよびセキュリティサービスを提供し、仮想ネットワークの可視性、ネットワーク脅威からのアプリケーション中心の保護、および一般的なネットワーク操作の自動化を提供します。

従来のインフラ環境においては、VLANベースの隔離やファイアウォールでのゾーン化を主なアプローチとして対応してきておりましたが、VLANの隔離はそもそもセキュリティの観点で隔離するのではありません。また、マニュアル作業のため安全とは言い切れません。また、横方向のネットワークには対応できないというデメリットがあります。

ファイアウォールのゾーン化については、VLANベースの隔離に比べればセキュリティという観点では優れておりますが、機器の値段はそれほど安いものではありません。

f:id:t_komiya:20190824221008p:plain

Flowは、完全な可視性とトラフィック制御を可能にするアプリケーション中心のポリシーを提供します。このポリシーモデルにより、管理者はトラフィックの送信元と宛先、またはマイクロセグメンテーションに関するきめ細かいルールを実装できます。これらの同じポリシーにより、アプリケーションVM内およびアプリケーションVM間を流れるトラフィックを視覚化できます。

Flowによるインフラの隔離であれば、部署ごとによりポリシーを容易に決めることができて、それがPrism Central上から操作が簡単にできるというところが特徴です。 

2.アプリケーションの隔離

f:id:t_komiya:20190824222216p:plain

アプリケーションのセグメンテーションについては、従来のものに関しては、各アプリケーションレイヤでVLANを割り当ててから、各アプリケーション/アプリケーションレイヤのFWポリシーを作成します。

この方法の場合、トラフィックはすべてFWに固定されてしまいますし、複雑化してコストもかかってしまいます。また、スケーラブルではないので、せっかくのハイパーコンバージド環境での利用も台無しになります。

f:id:t_komiya:20190824222701p:plain

FlowによるアプリケーションのセグメンテーションはVM単位にカテゴリ化します。(VLAN/クラスタ/ホストは任意)また、インバウンド/アウトバウンドのポリシー定義やティア内のポリシー定義を行います。
FWを利用した時に比べて非常にシンプルに設定が可能です。

3.セキュアなVDI環境の実現

f:id:t_komiya:20190824223833p:plain

こちらは従来のVDI環境におけるセキュアな環境ですが、こちらもFW内にアプリケーションに関するポリシーを設定するなどしなければならないため、複雑であり、VDI環境が拡張するにあたり、ポリシールールも手作業で大変になります。

f:id:t_komiya:20190824225030p:plain

逆にFlowで管理する場合はどうでしょうか。デスクトップユーザーの識別ができていることから、実際に人事異動でしたユーザーのポリシーについて、カテゴリごとにアプリケーション単位で適応できていれば、わざわざファイアウォール側での設定を行う必要はありません。またポリシー設定されていればマルウェアの拡散の防止にもなります。NutanixのAHV環境でVDIを構成する場合は、Flow導入するとセキュリティ対策も含めて便利になります。

4.コンプライアンスについて

f:id:t_komiya:20190824225540p:plain

カード決済などでよく利用されるPCIアプリケーションについては、かなり厳しいコンプライアンスが要求されると思います。各PCIアプリケーションについてファイアウォールのルールの適応を行うとともに、これを自動化していかないと毎回ユーザー登録するたびにマニュアルのオペレーションが発生します。これにより作業コストも上がりますし、横移動する際のセキュリティについても慎重に考えなければなりません。

f:id:t_komiya:20190824230445p:plain

Flowであれば、カテゴリ別設定することからマニュアル作業は極力削減することができます。また、ポリシーなどの監査についてもリモートホストのSyslogに転送することもできます。セキュリティオペレーターはそれらをモニタリングして、ポリシー違反なども発見することができます。

f:id:t_komiya:20190824230835p:plain

モニタリングとロギングに関する点については、実は先週のブログで紹介したAOS5.11に関するPrism Centralに関する記述の中で一部触れております。

Syslogに送信する機能およびセキュリティポリシーのインポート・エクスポート機能もサポートしておりますので、コンプライアンスを意識お客様は是非検証してみてはいかがでしょうか。

https://blog.lenovojp.com/entry/2019/08/19/000942

 

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