LTN Blog 〜 Lenovo Technology Network 〜

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

エッジコンピューティングについて(その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

 

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

AOS 5.11に関して~Prism / AHV機能編~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は前回に引き続いてNutanix AOS 5.11についてお話したいと思います。 今回はPrism Cental およびAHVに関する機能についてお話したいと思います。

Nutanix社提供の資料を利用させて頂いております。

1.Prism Central 5.11の新機能およびアップデート機能

f:id:t_komiya:20190818231712p:plain

f:id:t_komiya:20190818232119p:plain

f:id:t_komiya:20190818232255p:plain

Prism Centralのアップデート内容としては以下の点になります。

  • Nutanix オブジェクトストレージのサポート
  • コードレスタスクオートメーション(X-Play)
  • Syslogモニタリング
  • セキュリティポリシーのエクスポートおよびインポート
  • イメージ配置ポリシー
  • Flowのログでポリシーヒットをサポート
  • Nutanix Networking Service (Xi Cloud Services)
  • Xi Cloud ServicesNutanix Guest Tools(NGT)のサポート
  • カテゴリでESXiをサポート
  • エンティティメトリックの強化されたモニタリング
  • VM管理用のカテゴリベースのRBAC
  • カテゴリのマルチカーディナリティのサポート

全部を説明するとかなりの長文になってしまいますので、いくつかをピックアップしてお話します。

Nutanix オブジェクトストレージは前回にもご紹介させて頂きましたが、今回Prism CentralのUIから簡単にアクセスが可能になっております。

コードレスタスクオートメーションに関しては、次章にお話したいと思います。

それ以外にSyslogのモニタリング機能やセキュリティポリシーのエクスポート・インポート機能のサポート、Xi Cloud Serviceへのオンプレミス環境からの接続時におけるVPN機能のサポートやNutanix Guest Toolsのサポートがあります。

2.コードレスタスクオートメーション(X-Play)

f:id:t_komiya:20190818231442p:plain

イメージの中にも記載がありますが、こちらはIFTTT(イフト)の機能がサポートされおります。

IFTTTとは、一言でいうと連携機能のことです。「IF This Then That」の頭文字をとって、「もし、これをしたら、あれをする」という意味です。

例えば、特定の仮想マシンのメモリが足りなくなった場合に、リソースが余っているなら特定の仮想マシンに対してメモリ容量を増やしてあげるなどの対策を自動的に行うものです。

IFTTTを起動させる条件を「トリガー」、それによって自動的に行われる動作を「アクション」と呼びます。

自動化を試してみたい方には是非お奨めの機能だと思います。

 

なお、X-Playを利用するためにはPrism Proライセンスが必要です。また、X-Playでは、Prism Centralのみが5.11である必要があり、Prism Elementを5.11にアップグレードする必要はありません。

 

3.AHV 5.11の新機能およびアップデート機能

f:id:t_komiya:20190818234301p:plain

AHVに関するアップデート内容としては以下の点になります。

  • br0アップリンク構成のアップデートをサポート
  • AHVクラスターでのコンピュート専用ノードのサポート(AHVのみ)
  • AHVおよびHyper-VクラスターのVMにおけるUEFIサポート

br0アップリンクに関する内容については、イメージ内に詳細内容を記載しております。

コンピュート専用ノードに関する内容は次章にご紹介いたします。

UEFIサポートについては、AHVおよびHyper-Vの2つのプラットフォームでUEFIファームウェアを使用したVMの起動をサポートするようになりました。

4.AHV 5.11の新機能およびアップデート機能

f:id:t_komiya:20190818235014p:plain

コンピュート専用ノードはCPUおよびメモリのリソースのみをNutanixクラスタに追加するノードになります。そのため、CVMは内部に存在しません。AHVでサポートしているHAやADSなどの機能もそのまま利用できます。

ファームウェアのアップデートはLCMで行います。

現状こちらの機能はNXシリーズおよびXCシリーズ、Ciscoのプラットフォームがサポートとのことで、今後他社のプラットフォームにもサポートして頂きたいですね。

また、コンピュート専用ノード構成するにあたり、最低要件もありますので合わせて記載致します。

コンピュート専用ノードを利用する際の最低要件

  • コンピュート専用ノードを追加する前に、Nutanixクラスターは少なくとも4ノードのクラスター構成が必要
  • クラスター内のコンピュートノードとHCノードの比率は 1CO:2HCを超えてはいけない
  • クラスター内のHCノードはオールフラッシュで構成する必要がある
  • HCノード上のCVMに割り当てられるvCPUの数は、クラスター内のすべてのコンピュート専用ノードで利用可能な コアの総数以上である必要があります
  • すべてのHCノードに割り当てられたNICの帯域幅の合計は、クラスター内のすべてのコンピュート専用ノードに 割り当てられた合計NIC帯域幅の2倍である必要がある
  • コンピュート専用ノードのAHVバージョンは、クラスター内の他のノードと同じにする必要がある

コンピュートノードを構成する場合はFoundationからコンピュート専用ノードを構成してから、既存のPrismからノード追加でコンピュート専用ノードを選択する形になります。

是非構成する際はご注意下さい。

 

最後に、5.11になってソフトウェアのライフサイクルについてもお話しておきたいと思います。

5.LTSとSTSについて(アップデート)

f:id:t_komiya:20190818235826p:plain

今回リリースしたAOS 5.11については、STS(Short Term Support)になります。そのため、サポート期間は6か月になります。

前回ご紹介した時から内容が若干修正されているようですので、赤字でわかるようにしておきました。(イメージ参照)

6.AOSのライフサイクル

f:id:t_komiya:20190819000051p:plain

こちらが最新のAOSのライフサイクルになります。

前回内容と比べると、AOS5.5に関するサポートが長くなっております。

AOS5.11を利用される方は、サポート期間中に注意しながらご利用下さい。

7.AOSのアップグレードパスについて

f:id:t_komiya:20190819000312p:plain

アップグレードパスについては、Nutanixのポータルサイトからも確認できます。

今回は一例として、AOS5.5.9からのアップグレードパスを記載してみました。

実際にアップグレード作業する前に、ご確認下さい。

また、作業前に注意事項もポータルサイトに記載がありますので、是非ご覧ください。

https://portal.nutanix.com/#/page/docs/details?targetId=Web-Console-Guide-Prism-v510:upg-upgrade-checklist-r.html

 

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

 

AOS 5.11に関して~AOS機能編~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日は8月6日にリリースされたNutanix AOS 5.11についてお話したいと思います。

機能がかなり追加されておりますので、今回はAOSの機能をメインで紹介いたします。

Nutanix社提供の資料を利用させて頂いております。

1.AOS 5.11のメジャーアップデート

f:id:t_komiya:20190818104017p:plain

今回のアップデート内容としては以下の点になります。

  • ストレージのサービス品質 (QoS) 【パフォーマンスと復元力】 
  • Volumesのネットワークセグメンテーション(iSCSI)トラフィック【セキュリティ】
  • ストレージ容量スケール】
  • DR 【データ保護】
  • Nutanix Guest ToolsにおけるESXiのサポート

QoSに関しては、VMwareでいうところのStorage I/O Controlになります。
Volumesに関してもネットワークセグメントを分けられるようになっています。

ストレージ容量については、大容量ディスクに対応しておりますが、こちらは制限事項もありますので、合わせてご紹介したいと思います。

また、オブジェクトストレージもリリースされておりますが、名称が変更(Nutanix Objects)されておりますので合わせてお話します。

DRについては、ESXi関連の対応がメインになりますが、今回SRM(Site Recovery Manager)において、NearSyncが対応しております。

2.ストレージQoS

f:id:t_komiya:20190818105243p:plain

ストレージQoSは、管理者が仮想マシンのパフォーマンスを管理するためのきめ細かな制御を提供し、システムがすべてのワークロードに対して一貫したパフォーマンスを提供するようにします。制御可能なノブを使用して、ストレージレイヤーが個々の仮想マシンに提供するIOPSを制限できます。

ライセンスはProエディション以降で利用可能になります。ハイパーバイザーはESXiとAHVで対応しています。

f:id:t_komiya:20190818105537p:plain

QoSライクの機能はすでにNutanixには実装済みで、例えば容量とパフォーマンスに基づいたデータのコピー機能ががあります。(説明は省略させて頂きます)

f:id:t_komiya:20190818105809p:plain

さらに機能追加という形でADS(Acropolis Distributed Scheduler)などもNutanix全体のリソースを見ながら、単一ホスト内でリソースが不足した場合の仮想マシンの移行先を決定します。(説明は省略させて頂きます)

f:id:t_komiya:20190818110036p:plain

IOPSはストレージレイヤーが1秒間に処理できるリクエストの数になります。ノイジーネイバーの多いVMがシステムリソースを過度に使用しないように、VMにスロットル制限を設定できます。

 

ノイジーネイバー(うるさい隣人)に関する記事はインターネット上でも数多く紹介されているので、是非ご覧ください。

https://www.itmedia.co.jp/enterprise/articles/1611/10/news010.html

3.ネットワークセグメンテーション f:id:t_komiya:20190818111008p:plain

サービスのネットワークセグメンテーション

トラフィックをコントローラーVM上の別のvNICに制限し、独自の物理NICを持つ専用仮想ネットワークを使用して、サービスに関連付けられたトラフィックを保護できるようになりました。このタイプのセグメンテーションは、サービス固有のトラフィックの真の物理的分離を提供します。このリリースは、Nutanix Volumesのネットワークセグメンテーションをサポートしています。

ライセンスはStarterエディション以降で利用可能になります。ハイパーバイザーはESXiとAHVで対応しています。

f:id:t_komiya:20190818111107p:plain

この機能を利用することにより、基本的にサービス (この場合はVolumes)を新しいBridge (またはESXiの場合は仮想スイッチ)に接続し、 クラスター内部の各ノードの特定の物理ポートのみに 接続可能。 そのサービスからのすべてのトラフィックは、 そのBridge/物理ポートの組み合わせのみを通過させます。

3.高密度ストレージノード

f:id:t_komiya:20190818111933p:plain

1ノードあたり最大120 TiBのサポート

・Foundation 4.4以降のAOS 5.11は、ノードあたり最大120テビバイト(TiB)のストレージをサポートするようになりました。(正確には容量表記はこちらになります)

・Foundationソフトウェアは、プラットフォームモデルまたはストレージ容量に応じて、各コントローラーVMに割り当てられたデフォルトのメモリとvCPUの数をプロビジョニングします。

また、今回のストレージノードを利用するにあたり、必要な要件がありますので、以下に記載致します。

必要な要件:

1.最大ノード容量あたり120TB 12TB x 10

2.ノードごとに少なくとも2つのSSDが必要

3.HDDとSSDの比率は少なくとも2:1

4.ノードごとに合計7.68TB以上のSSD容量が必要 (3.84TB x 2)

5.CPUごとに最低12の物理コアが必要。ノード自体はデュアルソケットが必須

6.各CVMには12個のvCPUと36GBのサイズが必要

 

こちらのストレージノードについては、現状は以下の機種で対応しています。

NX-8155-G6

NX-5155-G6

ThinkAgile HX5520 (Lenovo)

上記の以外の他社製品は各社にご確認下さい。

4.オブジェクトストレージ(Nutanix Objects)

f:id:t_komiya:20190818112703p:plain

オブジェクトストレージについては、先にもお話しましたが、今回からNutanix BucketsからNutanix Objectsに変更に名称が変更になっております。

S3互換のAPIがサポートされ、導入も簡素化されています。

データの保管についてもWORM対応やセキュリティもSEC 17a-4準拠になっております。

バックアップとしても利用可能で、10ノードで1PB程度の容量にもスケールアウトします。

f:id:t_komiya:20190818113318p:plain

こちらのNutanix Objectですが、2TBの容量があればお試しでご利用可能だそうです。

バックアップソフトウェアなどで利用する場合にも、REST APIでオブジェクトストレージバックアップ可能なソフトウェア(Veeam , Commvault)などが必要になりますので、対応プラットフォームなどを確認してご利用下さい。
 

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

 

Blockchainに関して(その2)~Hyperledger Fabricおよびアーキテクチャについて~

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はBlockchainのその2と題して、オープンソースのブロックチェーン技術のHyperledgerについての簡単なご紹介と、ソリューションにおけるアーキテクチャをご紹介したいと思います。

 

1.Hyperledger Fabricについて

Hyperledger Fabricはブロックチェーンフレームワークの実装であり、The Linux FoundationがホストするHyperledgerプロジェクトの1つです。モジュラーアーキテクチャを備えたアプリケーションまたはソリューションを開発するための基盤として、Hyperledger Fabricを使用すると、コンセンサスサービスやメンバーシップサービスなどのコンポーネントをプラグアンドプレイできます。Hyperledger Fabricはコンテナ技術を活用して、システムのアプリケーションロジックを構成する「チェーンコード」と呼ばれるスマートコントラクトをホストします。Hyperledger Fabricは、最初のハッカソンの結果として、当初はDigital AssetとIBMから提供されました。

f:id:t_komiya:20190812213727p:plain

オープンソース、エンタープライズグレード、許可された分散型台帳テクノロジープラットフォーム であり、高度なモジュール化および構成可能なアーキテクチャより、幅広いユースケースに対応した革新性、汎用性 最適化を実現します。

各メンバーが見ることができる台帳のトランザクションを制限するために、チャネルを持つ許可されたネットワークを作成する機能を有し、Goで記述され、Dockerコンテナで実行されるチェーン コード(スマートコントラクト) で構成されます。

 

2.Hyperledger Fabricのコンポーネント

f:id:t_komiya:20190812214020p:plain

Hyperledger Fabricのコンポーネントは以下の3つから構成されます。

 

CACertificate Authority:認証機関

  • IDの登録、証明書の発行、証明書の更新と取り消し

オーダーサービス

  • 承認されたトランザクションを受け入れ、ブロックに順序付けし、ブロックをコミットしているピア(対等者)に配信します

ピア(対等者):

  • 台帳インスタンスとチェーンコードのインスタンスをホストします
  • ピアの承認
  • トランザクションのシミュレーションと承認
  • ピアのコミット
  • トランザクションをブロックチェーンにコミットする前に、承認されたトランザクションを検証し、 トランザクション結果を検証します

それでは、ブロックチェーンにブロックが追加されるフローについて、イメージで紹介したいと思います。

 

2.ブロックチェーンにブロックを追加

f:id:t_komiya:20190812214300p:plain

認証機関とオーダーサービスおよびピアの承認とピアのコミットおよびクライアントアプリケーションをイメージのように配置されていたとします。

f:id:t_komiya:20190812214644p:plain

クライアントアプリケーションからトランザクションをブロックチェーンに送信します。

f:id:t_komiya:20190812214754p:plain

ピアの承認に関して、ブロックチェーンの現時点の状態からトランザクションをシミュレートして、Read/Writeのセットを生成してクライアントアプリケーションに応答を返します。

f:id:t_komiya:20190812214944p:plain

クライアントアプリケーションはRead/Writeのセットを取得して、その情報をオーダーサービスに転送します。

f:id:t_komiya:20190812215113p:plain

オーダーサービスは送信されたRead/Writeのセットをブロックに配置します。

f:id:t_komiya:20190812215255p:plain

オーダーサービスはピアに対してブロックの情報を送信します。

f:id:t_komiya:20190812215355p:plain

ピアのコミットからRead/Writeのセットを実行して、トランザクションがまだ有効かどうか確認し、有効な場合はブロックチェーンにコミットするか、無効なトランザクションを送り返します。

f:id:t_komiya:20190812215555p:plain

ブロックチェーンの状態の終わりがクライアントアプリケーションに返送されます。

 

これらの一連の動作がブロック追加時に行われます。

次にブロックチェーンのソリューションを利用するときに必要なアーキテクチャについてお話したいと思います。

f:id:t_komiya:20190812215833p:plain

ブロックチェーンを利用する際に利用するプラットフォームとして、主に利用されるのがKubernatesのコンテナになります。

Kubernetes(K8s)は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するためのオープンソースシステムであり、アプリケーションのグループ化、デプロイ、スケーリング、自己修復が可能です。

Kubernatesは以下のもので管理されています。

 

チャート

  • Kubernatesコンポーネントを定義するテンプレートのバンドル

Helm(パッケージマネージャ)

  • チャートをパッケージ化、検索、および展開を可能にします

 

3.ソリューションアーキテクチャ

f:id:t_komiya:20190812220352p:plain

Kubernatesレイヤにおけるアーキテクチャをお話します。

今回はThinkAgile HXにフォーカスしてお話したいと思います。

ThinkAgile HXで利用可能なコンテナプラットフォームとしては、Nutanix KarbonおよびRedhat Openshiftの2つになります。

こちらの二つに関しての特徴は以下の通りです。

Nutanix Karbon

  • 効率的なワンクリックKubernates
  • 高可用性な導入が可能
  • 永続的なストレージのサポート:Volumes / FilesをサポートしたCSI

Red Hat OpenShift

  • レノボのリファレンスアーキテクチャ
  • 高可用性な導入が可能
  • 永続的なストレージのサポート:NFS

Karbonについては、Nutanixプラットフォームの使いやすさの兼ね備えたコンテナプラットフォームであり、Redhat Openshiftについてはレノボのリファレンスアーキテクチャになっています。

こちらが揃ったら、次にアプリケーションを搭載していきます。

f:id:t_komiya:20190812221237p:plain

コンテナ上にブロックチェーンに必要なアプリケーションのPodsを作成し、その中で認証機関のパッケージをインストールしてIDを作成します。

f:id:t_komiya:20190813002127p:plain

次にオーダーサービスをインストールします。オーダーサービスに相当するものはApache Kafka(スケーラビリティに優れた分散メッセージキュー)およびFabric Orderer(クライアントから送付されたトランザクションの順序付けをし、ブロックチェーンネットワーク内の Peer に送信)になります。

インストール後はOrder IDをセットアップします。

f:id:t_komiya:20190812222042p:plain

最後にインストールするのが、Peerに関するアプリケーションになります。Apache CouchDB(ドキュメント指向のオープンソースデータベースNoSQLの分類に属します)とFabric Peerになります。

こちらをセットアップ後にChannelを作成して、Channelに参加することでブロックチェーンを利用できます。

 

最後にHyperledgerの画面をご紹介しておきます。

f:id:t_komiya:20190812223139p:plain

【メイン画面】

f:id:t_komiya:20190812223245p:plain

【Script File】

f:id:t_komiya:20190812223404p:plain

【Transaction Record】

 

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

Blockchainに関して(その1)

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はBitCoinなどで利用されているテクノロジーのブロックチェーンをお話したいと思います。内容については、複数回でお話したいと思います。

 

まず、ブロックチェーンをWikipediaなどで調べると、分散型台帳技術、または、分散型ネットワークと呼ばれ、ビットコインの中核技術を原型とするデータベースである。ブロックと呼ばれる順序付けられたレコードの連続的に増加するリストを持つ。各ブロックには、タイムスタンプと前のブロックへのリンクが含まれている。理論上、一度記録すると、ブロック内のデータを遡及的に変更することはできない。ブロックチェーンデータベースは、Peer to Peerネットワークと分散型タイムスタンプサーバーの使用により、自律的に管理される。と記載があります。

 

WikiPediaのURL(Blockchain)

https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AD%E3%83%83%E3%82%AF%E3%83%81%E3%82%A7%E3%83%BC%E3%83%B3

 

では、そのブロックチェーンにどのようなコンポーネントが存在するのかお話したいと思います。

1.ブロックチェーンについてして理解してみよう

f:id:t_komiya:20190812090612p:plain

ブロックチェーンは3つの主要コンポーネントでなりなっています。

3つの主要コンポーネント

  • Distributed Ledger Database【分散台帳データベース】
  • Consensus Network mechanism【コンセンサス(合意型)ネットワークアルゴリズム】
  • Smart Contract execution environment【スマートコントラクトな実行環境】

Peer to Peerで動作していることから、それぞれのクライアントがデータベースを持ち、お互いのトランザクションを合意しながら処理を行うようにします。そのため、過去に発生したログなどは基本的に削除することはできません。

このように、過去の履歴をもとに処理を行うことから、サプライチェーンなどやオークションサイトなどにも利用されることがあります。

2.Distributed Ledger Database【分散台帳データベース

f:id:t_komiya:20190812092803p:plain

分散台帳データベースとありますが、フルマネージド型のデータベースとも言えます。人によってはデータベースではないという方もいらっしゃいますが、一般的なデータベースと比較するものではないと考えます。

 

データの変更不可能性

ブロックチェーンはブロックと呼ばれる単位のデータの固まりを繋げたものになります。

ビットコインのブロックチェーンのブロックはgenesis blockと言う最初のブロックから始まり、ブロック内にはそのブロックのメタデータであるヘッダー部がある。

ヘッダーにはそのブロックが何個目(ブロック高)かや前のブロックのハッシュ値(previous block hash)が含まれる

前のブロックの内容が変更されるとブロックに含まれるprevious block hashも変更されるので、このブロック自体のhashも変更される。

ブロックの内容を変更するにはその後の世代のすべてのhash値を再計算しなければならず、これは非常に困難なためこのことがブロックチェーンの変更不可能性の肝となっている

f:id:t_komiya:20190812093631p:plain

ブロックの構造ですが、5種類のフィールドで定義され、ブロックヘッダーについては、さらに6種類のフィールドで定義されます。

詳しい説明は長くなるので割愛させて頂きますが、過去に処理したトランザクションを参照しながらブロックが構成されることから、ネットワーク全体で巨大なジャーナルを所有することになるため、非常に大きなデータ量や処理能力を求められるシステムになります。

3.Consensus Network mechanism 【コンセンサス(合意型)ネットワークアルゴリズム

f:id:t_komiya:20190812095102p:plain

 

Proof of Workとは、参加者全員が、同じブロックをブロックチェーンに追加するための仕組みです。
ビットコインでは、同じブロック(取引データ)を含むブロックチェーンが、参加者によって管理されています。
仮に、参加者が自分の好きなブロックを、ブロックチェーンに追加できるとしたら、同じデータを持つブロックチェーンを、みんなで管理することはできません。
Proof of Workとは全体で適切な意思決定を行うために、必要な仕組みと、まえがきで解説しましたが、 『全体の意思決定』=『参加者が同じブロックチェーンを管理する』ということです。

https://moblock.jp/articles/17193  から引用

 

Proof of Elapsed Timeとは、Proof of Workにおけるマイニングによる作業証明の代わりに、その名が示すところの通り消費した時間の証明になっております。

 

ビザンティン・フォールトトレラントとは、分散コンピューティングにおいて、アルゴリズムを実行中に発生する故障・障害であり、不作為障害 (omission failures) と作為障害 (commission failures) が含まれる。不作為障害とは、クラッシュ、要求を受信しそこなうこと、応答を返しそこなうことなどを指す。一方、作為障害とは、要求を不正に処理すること、局所状態が壊れること、要求に対して不正または一貫しない応答を返すことなどを指す。ビザンティン・フォールトトレラントが発生すると、ビザンティン・フォールトトレラント性を備えていないシステムは、予期しない動作をすることがある。

https://ja.wikipedia.org/wiki/%E3%83%93%E3%82%B6%E3%83%B3%E3%83%81%E3%83%B3%E5%B0%86%E8%BB%8D%E5%95%8F%E9%A1%8C から引用

 

Proof of Authorityとは、参加者が意見が一致せず、正しい意思決定できない場合、中央で管理している管理者に意思決定を委ねるものです。二重支払いなどを防ぐために必要になる機能となります。

 

4.Smart Contract execution environment 【スマートコントラクトな実行環境

f:id:t_komiya:20190812102620p:plain

スマートコントラクトは、その名前の通り、コントラクト(契約)をスマートに行えるプロトコルのことです。つまりスマートコントラクトとは契約の自動化であり、契約の条件確認や履行までを自動的に実行させることができます。
取引プロセスを自動化できるため、決済期間の短縮や不正防止、仲介者を介さないことによるコスト削減にも寄与すると期待されており、各国で取り組みが行われています。また、ブロックチェーン上でスマートコントラクトを利用すると、ユーザー同士が直接取引を行う非中央集権型のサービスを実現でき、社会に大きな変化をもたらす可能性があると言われています。

5.パブリックブロックチェーンと許可されたブロックチェーン

f:id:t_komiya:20190812102947p:plain

ブロックチェーンには2種類あります。

パブリックブロックチェーン(パブリックチェーン):

  • 誰でもネットワークに参加でき、トランザクションを読み書きできます
  • ネットワーク内の悪意のあるアクターの可能性を高める、不明な参加者のID

許可されたブロックチェーン(プライベートチェーン):

  • セキュリティリスクの軽減、取引を希望するパートナーのみが取引の一部です
  • 関係者のみに見える取引
  • 機能:データプライバシー、情報共有、不変性

こちらの種類にはそれぞれメリット・デメリットがあります。内容についてはイメージを参照して頂ければと思います。

実際にブロックチェーンを利用する場合には、正しい適合を見つけていく必要があります。

f:id:t_komiya:20190812103345p:plain

正しい適合性を見つけるためには、データベースの中で参加者の意思決定や過去のトランザクションに基づいて処理を行う必要があります。実際には利用シーンによってはブロックチェーンが必要にならないようなケースもあります。イメージは参考情報としてみて頂ければと思います。

 

参考として、サプライチェーンにおけるブロックチェーンの説明のイメージを載せておきます。

f:id:t_komiya:20190812212052p:plain

 

次回のブログは、オープンソースで実現するブロックチェーンHyperledgerやソリューションのアーキテクチャについてお話したいと思います。

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

 

VDIにおけるいくつかの注意事項

皆さん、こんにちは レノボ・エンタープライズ・ソリューションズ 小宮です。本日はVDIにおける注意事項をいくつかお話したいと思います。

VDIを導入したものの、運用上使い物にならないものを構築しては意味がなくなってしまいますので、今回は運用上役立つ点をいくつか紹介したいと思います。

 

1.Windows10のライフサイクルについて

f:id:t_komiya:20190804162904p:plain

Windows10のライフサイクルについてですが、エディションにより期間が異なりますが、通常利用されるProエディションは機能更新プログラムがリリースされてから18か月というスパンになります。今までは長期間のサポートになっていましたが、期間毎にリリースされるバージョンで管理していく必要があります。これにより、Nutanixで管理する場合に対応しなければならないのが、AOSも合わせてこちらをアップデートする必要があります。

AOSのライフサイクルについては以下のURLをご参照下さい。

1年ぶりのLTS対応AOS5.10 とその追加機能のご紹介~AOS5.10の機能紹介~ - LTN Blog 〜 Lenovo Technology Network 〜

ここでAHVに関してはコメントしていきたいと思います。f:id:t_komiya:20190804163944p:plain

Windows10については、現状だと1803以降についてお話します。

Windows10はHyper-Vのプラットフォームを推奨しているようですが、それはWindows10が仮想化環境を意識して最適な状況で動作しようとします。(詳細は上の説明を参照して頂ければと思います)

また、Windows10 1803以降でハイパーバイザーレベルのSyNC タイマー(Windows10においてTimeサーバーを管理)になることになります。 

こちらの機能はAOSの5.5.8 以降のLTSで対応可能になっております。

(STSはAOS5.9.1以上になります)

2.Officeのバージョンやセキュリティパッチについて

 こちらにブログにはOfficeのバージョンごとのパフォーマンスデータを掲載することはしませんが、Office 2016とOffice2019でLogin VSIなどの数値は異なります。どのようなシーン・どのような環境なのかも含めて、VDI導入の際にOffficeのバージョンも含めてテストされることを推奨いたします。(Office2019のVSIの数値が劣ることがあります)

また、セキュリティパッチについては、IntelのCPUレベル(Spectre / Meltdown / ForeShadow)の脆弱性が発見されています。是非導入時にセキュリティパッチも含めての検証をお願いします。

 

3.GPUVDIソリューションにもたらすメリット

f:id:t_komiya:20190804170034p:plain

 GPUというとWorkStationに利用されることが思い浮かぶと思いますが、もちろんCAD向けVDIについてはGPUを利用することも考えられますが、昨今はNVIDIA社のGPUを利用したWindowsのVDI環境で利用されることがあります。Officeアプリケーションもスピードの向上も考えられますが、特にGPUがVDIで利用されるシーンとしては、Skypeなどの音声処理の時の効果が大きいようです。

また、GPUについては、VDI環境で利用した場合について顧客満足度が高い結果も出ております。以下のURLにLakeSide Softwareが測定した結果もございますので、参考にして頂ければと思います。

https://twitter.com/WillFulmer/status/1102968227213254656

f:id:t_komiya:20190804170643p:plain

 また、利用シーンについてGPUがもたらす効果をまとめてみました。GPUボードは少し高価にように思えますが、業務が効率化することが望めるなら是非検討してみてはいかがでしょうか。

4.VDIのサイジングルールとガイドライン

f:id:t_komiya:20190804171011p:plain

VDIのサイジングルールとガイドラインについてですが、様々なルールがインターねネット上に上がっているので、こちらでは一般的なコメントをしたいと思います。

事前のアセスする環境があるかと思いますが、最近はLiquidwareやLakesideなどのツールを利用して実施することがありますが、仮想環境で導入されているお客様は仮想化でユーザーの収容度を測れるツールなどもありますので、そのようなツールで現状把握してみてはいかがでしょうか。

データからサイジングする場合についてですが、メモリ・CPU(MHz単位)の使用率、ディスク容量などがあります。アプリケーションの仮想化を行う場合はアプリケーションの一覧も対象になります。

OSのバージョンなどやOfficeのバージョン、セキュリティパッチもサイジングに大きく影響与える要素であるため、そのあたりの考慮を忘れずにお願いします。

f:id:t_komiya:20190804171509p:plain

f:id:t_komiya:20190804171526p:plain

VDIを検討する際に、CPUの選択がユーザーの集約度に大きく変わります。

ただ、ユーザーに詰め込みすぎるのもHAでの切り替え時間もあったり、消費電力に大きく影響することもありますので、コアの多いものや周波数の高いものを選択するかはアプリケーション次第で決定したほうがと良いと思われます。

また、どのようなユースケースなのかも把握する必要があります。

リソース要件もありますが、アプリケーションの利用方法やデスクトップが永続的に利用するタイプか毎回ログインするたびにデスクトップがクリアされる非永続型なのかによって、システムの選択方式が変わりますのでご注意下さい。

5.クラスタのサイズの決定

f:id:t_komiya:20190804172207p:plain

VDIでHCIを選択する際にスケールアウトできるからVDI!という感じでシステムを決定して、1つのクラスタの中にVDIのノードを定義してしまうと、運用上の問題が出てきてしまいます。

例えば、こちらは一例としてESXiでクラスタを構成した場合、ファームウェアのアップデートするときのメンテナンス(システム停止はしませんが)を記載しています。

16ノードのクラスタで運用した場合に約4時間程度のメンテナンスになりますが、これが32ノードの場合は8時間くらいかかります。

アップデート作業中は管理者は現地にずっと待機しなければならず、システム停止はしなくとも、メンテナンスの作業が長くなることは管理者の対応も大変ですので、1クラスタのノード数は是非部署単位で小分けることをお薦めします。

f:id:t_komiya:20190804172813p:plain

こちらは約2000ユーザーを1つのポッドに定義して、25000ユーザーを収容した例になります。VDI案件は大規模になりやすいことから、運用しやすいポッドの定義して是非メンテナンスの短いシステムの検討をよろしくお願い致します。

 

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