Dell EMC Streaming Data Platform：アーキテクチャ、構成、および考慮事項

エグゼクティブサマリー

このドキュメントでは、ストリーミングデータをリアルタイムで取り込み、保存、分析するためのスケーラブルなソリューションであるDell EMC™ Streaming Data Platform (SDP)について説明します。このペーパーでは、ソリューションのコンポーネント、論理的および物理的なインフラストラクチャ、構成の詳細、およびソリューションを選択して導入する際に考慮すべき点について説明します。

1 序章

モノのインターネット（IoT）は新たな可能性を約束してくれますが、それを解き放つためには、組織はデータに対する考え方を変えなければなりません。IoTの出現により、世界中に散らばっているセンサーやデバイスからのストリーミングデータを処理する新しいクラスのアプリケーションが登場しました。理論的には、大量のデータを即座に連続的かつ無限に処理・分析することで、リアルタイムの洞察力に変えるという解決策はシンプルです。しかし、ストリーミングIoTデータの管理はそれほど単純ではありません。レガシーインフラストラクチャは、データタイプの異なる数百万のデータソースからのIoTデータのストリーミングをサポートするように作られていません。ストリーミングIoTの世界では、連続的かつ無限のストリームを消費するリアルタイムアプリケーションの世界へのシフトが必要です。

今日では、何百ものアプリケーションがIoTパズルのさまざまなピースを解決しようとしています。このシナリオでは、アプリケーションが変化し続け、さまざまな相互運用性の要件を持ち、独自のインフラストラクチャを必要とするため、完全なエンドツーエンドのソリューションを構築することが困難になります。この複雑なシステムを管理するには、コストと時間がかかり、実質的なメンテナンスが必要になります。

Dell EMC Streaming Data Platformは、これらの問題を解決するために設計されています。インフラストラクチャスタックを簡素化することで、幅広いユースケースに対応するように設計された理想的なエンタープライズソリューションです。

1.1 製品概要

Streaming Data Platformは、リアルタイムで継続的にストリーミングされたデータを取り込み、保存、分析するための拡張性に優れたプラットフォームです。このプラットフォームは、リアルタイムデータと収集したヒストリカルデータの両方を同じアプリケーションで同時に処理することができます。

Streaming Data Platformは、さまざまなソースからのストリーミングデータを取り込んで保存します。これらのソースには、IoTデバイス、ウェブログ、産業用オートメーション、金融データ、ライブビデオ、ソーシャルメディアフィード、アプリケーション、イベントベースのストリームなどが含まれます。このプラットフォームは、低レイテンシーと高可用性を確保しながら、複数のソースからの数百万件のデータストリームを処理することができます。

このプラットフォームは、ストリームの取り込みとストレージを管理し、ストリームを処理する分析アプリケーションをホストします。利用可能なインフラストラクチャ上でデータ処理と分析ジョブを動的に分散します。また、ワークロードの変化に応じて、リアルタイムで処理要件を満たすために、リソースを動的かつ自動的にスケーリングします。Streaming Data Platformは、以下の機能を単一のソフトウェアプラットフォームに統合しています。

• ストリームの取り込み。このプラットフォームは、静的なものでもストリーミングでも、あらゆるタイプのデータをリアルタイムで取り込みます。データの歴史的なファイルであっても、取り込むと、データのバウンデッドストリームになります。
• ストリームストレージ。弾力的な階層型ストレージは、リアルタイムデータへの即時アクセスと無限のストレージ、および履歴データへのアクセスを提供します。この緩く結合された長期ストレージにより、すべてのストリーミングデータソースに対応した無制限のデジタルビデオレコーダー（DVR）が可能になります。
• ストリームアナリティクス。内蔵のアナリティクスエンジンでリアルタイムのストリーム解析が可能。ヒストリカルデータとリアルタイムのストリーミングデータの解析が統合され、アプリケーション開発プロセスが簡素化されました。
• リアルタイムとヒストリカルの統一。このプラットフォームは、リアルタイムデータとヒストリカルデータを処理し、新しいストリームを作成して保存したり、企業のアラートツールに通知を送信したり、サードパーティの可視化ツールに出力を送信したりすることができます。
• プラットフォーム管理。統合管理は、データセキュリティ、構成、アクセス制御、リソース管理、直感的なアップグレードプロセス、ヘルスとアラートのサポート、ネットワークトポロジーの監視を提供します。
• ランタイム管理。Web ポータルを使用して、ストリームのプロパティを設定したり、ストリームメトリクスを表示したり、アプリケーションを実行したり、ジョブステータスを表示したりすることができます。
• アプリケーション開発。ディストリビューションにはAPIが含まれています。ウェブポータルは、アプリケーションの展開とアーティファクトの保存をサポートしています。

要約すると、このプラットフォームは、連続的にストリーミングされたデータを保存し、そのデータをリアルタイムで分析し、保存されたストリームの履歴分析をサポートすることができます。

1.2 アーキテクチャ

Streaming Data Platformアーキテクチャには、以下の主要なコンポーネントが含まれています。

• Pravega：Pravegaはオープンソースのストリーミングストレージシステムで、ストリームを実装し、連続的で束縛されないデータを保存または提供するためのファーストクラスのプリミティブとして機能します。このオープンソースプロジェクトは、Dell Technologiesによって推進、設計されています。詳細はPravegaのサイトを参照してください。
• Apache® Flink：Flinkは、大規模な束縛されていないデータと束縛されていないデータをリアルタイムで処理するための分散コンピューティングエンジンです。Flinkは、ストリーミングデータプラットフォームでストリーミング分析を実行するための主要なコンポーネントです。Flink は Apache Software Foundation のオープンソースプロジェクトです。
• Kubernetes：Kubernetes（K8s）は、コンテナオーケストレーションのためのオープンソースのプラットフォームです。K8s は、VMware® vSphere® 上で動作する Pivotal Container Service (PKS) を通じて配布されています。
• 管理プラットフォーム：管理プラットフォームは、Dell Technologies™が独自に開発したソフトウェアです。他のコンポーネントを統合し、セキュリティ、パフォーマンス、構成、監視機能を追加します。管理者、アプリケーション開発者、エンドユーザ向けのWebベースのユーザーインターフェースが含まれています。

図1は、Streaming Data Platformアーキテクチャの上位概念を示しています。

注: Streaming Data Platformは、Dell EMC Isilon™システムとDell EMC ECSをパーシステントストレージ用に、Apache Flinkをスティームアナリティクスエンジン用にサポートしています。Dell EMC ECSはSDP 1.1リリースからサポートされています。

1.3 ストリームの定義と範囲 

Pravegaでは、データをStreamに整理しています。Pravegaのサイトによると、Streamとは、耐久性があり、弾力性があり、追加のみで、束縛されていないバイトのシーケンスのことです。Pravegaのストリームは、追加のみのログデータ構造に基づいています。Pravegaは、追加のみのログを使用することで、データを耐久性のあるストレージに迅速に取り込むことができます。

ユーザーがPravegaにストリームを作成する際には、保存するデータの種類を示すためにJSONStreamSensorDataのような名前を付けます。Pravegaは、ストリームをScopeに整理します。Pravega Scopeは、ストリームのコレクションのための安全な名前空間を提供し、複数のストリームを含むことができます。各ストリーム名は同じScope内で一意でなければなりませんが、異なるScope内では同一のストリーム名を使用することができます。

ストリームは名前とスコープによって一意に識別されます。クライアントは、ストリームにデータを追加したり（ライター）、同じストリームからデータを読み込んだり（リーダー）することができます。

Streaming Data Platform内では、アナリティクスプロジェクトを作成することで、UI内にスコープが作成されます。アナリティクスプロジェクトを作成すると、Pravega Scopeが自動的に作成されます。Pravega Scopeの名前は、アナリティクスプロジェクト名から自動的に継承されるので、名前は慎重に選びましょう。どちらの名前も同じです。

2 Streaming Data Platform

ここでは、Streaming Data Platformとそのコンポーネントの概要を説明します。Pravega、Flink、およびPivotal Container Service（PKS）です。

2.1 Pravega

Pravegaは分散システムとして展開され、それはKubernetesの内部にPravegaクラスタを形成します。

Pravegaアーキテクチャは、コントローラインスタンス（コントロールプレーン）とPravegaサーバ（データプレーン）によって形成されたSDS（Software-Defined Storage）アーキテクチャを提供しており、Pravega Segment Storeとしても知られています。図2は、デフォルトのアーキテクチャの概要を示しています。ほとんどのコンポーネントは、ボリュームサイズやステートフルセットやレプリカセットあたりのレプリカ数などのカスタマイズが可能です。

2.1.1 Pravega Operator

Pravega Operatorは、Kubernetesのソフトウェア拡張です。Pravegaクラスタを管理し、Pravegaクラスタの作成、削除、サイズ変更などのタスクを自動化します。Streaming Data Platformのインスタンスごとに必要なPravegaオペレータは1つだけです。Kubernetesオペレータの詳細については、Kubernetesページのオペレータパターンを参照してください。

2.1.2 Bookkeeper Operator

Bookkeeper Operator は、Kubernetes に導入された Bookkeeper クラスタを管理し、Bookkeeper クラスタの作成・破棄、クラスタのリサイズ、ローリングアップグレードなど、Bookkeeper クラスタの運用に関連するタスクを自動化します。

2.1.3 Zookeeper Operator

Kubernetes での Zookeeper クラスタの展開を管理します。

2.1.4 Pravega サービスブローカー

Pravega サービスブローカーは、Pravega Scopeを作成したり削除したりします。また、これらのスコープは、関連する認証ポリシーとともに Keycloak に保護されたリソースとして登録されます。

2.1.5 Pravega Controller

Pravega Controllerは、Pravegaコントロールプレーンを実装するPravegaのコアコンポーネントです。Pravegaコントローラは、Pravegaクラスタ内で実行される様々な操作（ストリームの作成、更新、シール、スケール、削除などのアクション）のための中央コーディネータおよびマネージャとしての役割を果たします。また、異なるセグメントストアインスタンスに負荷を分散させる役割も担っています。コントローラインスタンスのセットは、Pravegaのコントロールプレーンを形成します。これらの機能は、ストリームに関する情報の取得、Pravegaクラスタの健全性の監視、メトリクスの収集、その他のタスクを実行するために拡張されています。通常、高可用性を実現するために、クラスタ内で複数のControllerインスタンス（少なくとも3つのインスタンスを推奨）が稼働しています。

2.1.6 Pravega Segment Store

Segment StoreはPravegaデータプレーンを実装しています。Segment StoreはStream Segmentsを管理するための主要なアクセスポイントであり、コンテンツの作成と削除を可能にします。PravegaクライアントはPravega Stream Controllerと通信して、どのSegment Storeを使用しなければならないかを識別します。Pravegaサーバーは、ストリーム内のデータを読み書きするためのAPIを提供します。データストレージには2つの層があります。

• Tier 1: この階層は、短期で低レイテンシのデータストレージを提供し、Streamに書き込まれたデータの耐久性を保証します。Pravega は Apache Bookkeeper™ を使用して Tier 1 ストレージを実装しています。Tier 1 ストレージは通常 Pravega クラスタ内で動作します。
• Long-Term Storage (LTS)：この階層では、Streamデータに長期ストレージを提供します。Streaming Data Platformは、Dell EMC IsilonとDell EMC ECSをサポートしており、長期ストレージを実装できます。LTSは一般的にPravegaクラスタの外部に配置されます。

デフォルトでは6つのSegment Storeがインストールされていますが、作業量に応じてこの数を増やすことができます。

2.1.7 Pravega Zookeeper

Pravegaは、Pravegaクラスタ内のコンポーネントとの連携にApache Zookeeper™を使用します。デフォルトでは、3台のZookeeperサーバがインストールされています。

2.1.8 Pravega InfluxDB

Pravega influxDBはPravegaのメトリクスを格納するために使用されます。

2.1.9 Pravega Grafana

Pravega Grafanaのダッシュボードには、Pravegaの運用と効率に関するメトリクスが表示されます。

2.1.10 Pravega Bookkeeper

PravegaはApache Bookkeeperを使用しています。短時間で低レイテンシのデータストレージを提供し、Streamsに書き込まれたデータの耐久性を保証します。導入時には、最低でも5つのBookkeeper（ブッキー）を使用してください。デフォルトでは、データの耐久性を保証するために、3つのレプリカをBookkeeperに保持する必要があります。

SDP リリース 1.1 では、Bookkeeper のパフォーマンスを向上させるための新しい設定オプションが導入されました。SDP 1.0 では、vSAN ストレージからの PVC を使用して Bookkeeper をプロビジョニングしていましたが、1.1 では、ローカルデータストアのディスクを使用して Bookkeeper をプロビジョニングするオプションが追加されます。このシナリオでは、各 Bookkeeper は、パフォーマンス向上のために専用のローカル データストア上で動作するようになります。この新しいオプションは、Bookkeeper on BOSH と呼ばれています。

注: BOSH 上の Bookkeeper での大きな変更点は、Bookkeeper が Kubernetes ポッド内で動作しないことです。各 Bookkeeper インスタンスは、専用の仮想マシン内に配置されます。Bookkeeper on vSAN を使用した SDP 1.0 から Bookkeeper on BOSH を使用した SDP 1.1 への移行はサポートされていません。

表 1 に、Streaming Data Platform のインストール時に設定する Bookkeeper の 4 つのパラメータを示します。

表 1 Bookkeeperのパラメータ

2.1.11 Pravegaのデータフロー

以下の手順と図は、データフローの書き込みと読み込みの処理の概要を示しています。

データフローを書き込む。

1. クライアントがコントローラに連絡して書き込み先を特定する。
2. コントローラは、セグメントとデータを書き込む場所のセグメントストアのURLを返す。
3. クライアントはセグメントストアに書き込む。
4. Apache Bookkeeper の Tier-1 にデータを書き込む。
5. Pravega からデータが書き込まれたことを確認する確認通知がクライアントに届く。並行して、データは Segment Store のキャッシュボリュームに保存される。
6. 非同期的に、データは長期ストレージにコピーされる。

データフローを読み取る。

1. クライアントがControllerに連絡して、読み取りを実行する場所を特定する。
2. Controllerは、セグメントとデータを読み取るためのセグメントストアのURLを返す。
3. データはセグメント・ストアに要求される。
4. Segment Store は、データが保存されている場所に応じて、キャッシュまたは長期ストレージから読み込む。この情報は、クライアントの視点からは隠されている。
5. データをクライアントに返す。

注：Apache Bookkeeper は「データフローを読む」シナリオでは使用されません。Apache Bookkeeper に保存されているデータは、復旧のためにのみ使用されます。

2.2 Flink

SDPは、管理されたApache Flink環境の形で分析計算機能を提供します。Flink クラスタは、SDP が Pravega のアクセス資格情報、ストレージ、および HA 構成を使用して Flink クラスタを自動的に構成するため、分析プロジェクトに簡単に導入することができます。FlinkアプリケーションのライフサイクルもSDPによって管理されているため、Flinkアプリケーションの展開、停止、開始、移行を簡単に行うことができます。

SDP 1.1 Flink イメージ環境には、Flink 1.8.3、1.9.2、および Flink 1.10.0 用のイメージが同梱されています。また、カスタム Flink イメージもサポートしています。

Streaming Data Platformでは、Flinkはアナリティクスプロジェクトに紐付けられています。アナリティクスプロジェクトは、ストリーミングまたは分析処理のための隔離された環境です。アナリティクスプロジェクトのプロビジョニングプロセスでは、以下のようなものが作成されます。

• プロジェクトのセキュリティ認証情報
• プロジェクトの資格情報で確保されたPravega Scope（プロジェクトと同じ名前）
• プロジェクト分析コンポーネント用ストレージ（NFSまたはECS S3でバックアップされている
• 共通のインフラストラクチャ コンポーネントを含む Kubernetes の名前空間 (プロジェクトと同じ名前)
  • Zookeeper クラスタ (デフォルトでは 3 ノード)
  • 安全なMavenリポジトリ(専用のDNS名でクラスタ外からアクセス可能)
  • プロジェクトの資格情報を含むKubernetesの秘密

アナリティクスプロジェクトが作成されると、ユーザーはニーズに応じて1つ以上のFlinkクラスタを作成することができます。デフォルトでは、Flink クラスターは 1 つのジョブマネージャーと n 個のタスクマネージャーで構成されています。クラスタ内のタスクマネージャーの数は、いつでも調整できます。SDPは、適切なPravegaの資格情報、ストレージ、および高可用性の構成でFlinkクラスタを自動的に構成するため、管理者の負担が軽減されます。解析プロジェクトの図については、図 3 を参照してください。

2.3 Pivotal Container Service（Kubernetes)

Kubernetes プラットフォームである Pivotal Container Service（PKS）の中では、配置構成をプランと呼んでいます。プランには、ワーカーの数、マスターの数、VMあたりのCPU、メモリ、ディスクなどの項目の設定が含まれています。これらのプランを使用してPKSクラスタを作成します。

Streaming Data Platformには2つのプランがあります。

スモール（テスト用）。

• 名称: 小
• Master/ETCDノードのインスタンス。1
• Master/ETCD VM タイプ: medium.disk (CPU: 2, RAM: 4 GB, disk: 32 GB)
• Master永続diskサイズ：50 GB
• Master/ETCD利用可能ゾーン：az1
• クラスタ上のWorkerの最大数。50
• Workerノードのインスタンス。3
• Worker VM タイプ: xlarge (CPU: 4、RAM: 16 GB、disk: 32 GB)
• Workerの永続的なdiskサイズ：50 GB
• Workerの利用可能ゾーン: az1

ラージ（本番用）。

• 名称：ラージ
• Master/ETCDノードインスタンス。3
• Master/ETCD VM タイプ: medium.disk (CPU: 2, RAM: 4 GB, disk: 32 GB)
• Master永続diskサイズ：30 GB
• Master/ETCD利用可能ゾーン：az1
• クラスタ上の最大Worker数。50
• Workerノードのインスタンス。5
• Worker VM タイプ。2xlarge (CPU: 8, RAM: 32 GB, disk: 64 GB)
• Workerの永続的なdiskサイズ：50 GB
• Workerの利用可能ゾーン: az1

注：これらの計画で定義されているワーカーノードの数は、デフォルト値に対応しています。実際の SDP 導入では、この値は変更される可能性があります。

3 論理的なインフラストラクチャ

Streaming Data Platformは、Kubernetes環境で動作するソフトウェアのみのプラットフォームです。ここでは、推奨されるアーキテクチャについて説明します。

VMware ESXi™ が各物理サーバーにインストールされています。SDP 1.1では、専用の管理ノードはなくなりました。すべての物理サーバーは、1つのVMwareクラスタの一部になりました。

VMware vCenter®内に展開されているのは、NSX-T、OPS Manager、Enterprise Pivotal Container Service（PKS）、BOSH、およびVMware Harbor Registryです。

SDPはPKSバージョン1.6.1をサポートしています。

PKSは、各新しいVMの管理とK8sクラスタの展開を担当します。K8s クラスタで実行できる SDP インスタンスは 1 つだけで、1 対 1 の関係を形成します。複数のSDPインスタンスを展開するには、他のK8sクラスタを展開する必要があります。そのK8sクラスタがPKSクラスタです。PKSクラスタの作成は簡単で、1つのコマンドで実行されます。唯一の制限は、VMware vCenter クラスターで利用可能な物理リソースです。

Streaming Data Platform 1.1では、4つの展開オプションがあります。詳細は表2を参照してください。

表2 クラスターサイズ

図4　Streaming Data Platformインフラストラクチャの論理図

3.1 Pivotalの構成要素

この項では、解決策のPivotal成分について説明します。

3.1.1 Operations Manager

Pivotal Operations Manager (Ops Manager)は、Enterprise PKS、BOSH、Harbor RegistryなどのPivotalコンポーネントの展開を管理するためのユーザーインターフェースを提供します。

3.1.2 Pivotal Container Service

Streaming Data Platformの実行にはKubernetes（K8s）環境が必要です。K8sクラスタの実行にはPivotal Container Service（PKS）を使用します。PKSは、Kubernetesクラスタの管理を簡素化するエンタープライズKubernetesプラットフォームです。また、現在のワークロードに応じて、環境を迅速にスケールアップまたはスケールダウンするための機能を提供します。

3.1.3 BOSH Director for vSphere

BOSH Director for vSphereは、複数のVM上でソフトウェアのプロビジョニングと展開を行うことができる強力なツールです。Pivotalプラットフォーム内では重要な要素となっています。PKSでは、BOSHを使用してKubernetesクラスタの実行と管理を行っています。

3.1.4 Harbor

HarborはPKSに付属しているDockerのレジストリです。Streaming Data PlatformのDockerイメージを保存するために使用します。

3.2 vSAN

VMware vSANは、単一のプラットフォームでストレージを管理できるストレージ仮想化ソフトウェアです。vSphere クラスタからアクセス可能なすべてのストレージ デバイスを共有データ プールに結合します。物理クラスタ ノードからプロビジョニングされたすべてのローカル ディスクがマージされ、vSAN ストレージ プールが形成されます。プールには、起動専用のノードやローカル リソースは含まれません。vSAN を使用すると、個別のアレイやストレージ ネットワーク ハードウェアを展開したり、維持したりする必要はありません。

Streaming Data Platformは、VM用のストレージをプロビジョニングするためにvSANを使用し、またKubernetesクラスタ内のストレージクラスとしても使用しています。Kubernetesのストレージクラスは、異なるポッドやコンテナに永続的ボリューム（PV）を動的にプロビジョニングするために使用されます。ポッドは永続的ボリュームクレーム（PVC）を消費し、PVCはPVを消費します。

KubernetesのストレージクラスとPVの詳細については、Kubernetesのストレージ概念のページを参照してください。

Streaming Data Platform 1.1 では、ESXi ノードあたり 4 台のディスクを vSAN 用に使用することを推奨しています (1 台の NVMe キャッシュドライブと 3 台の SSD 容量ドライブを 1 つのディスクグループに編成)。この新しいモデルでは、残りのディスクをBookkeeper on Bosh用に予約することができます。

例えば、ESXiノードにNVMeローカルディスクが5台、SSDローカルディスクが3台ある場合、4台（NVMe1台＋SSD3台）のディスクをvSAN専用とし、3台のNVMeディスクをBookkeeper VMに使用することになります。また、ディスク障害に対応するために、NVMeディスクを1台予備として確保しておくことをお勧めします。

vSAN構成のハイライトと推奨事項には、以下のようなものがあります。

• 初期設定では、利用可能な最高のハードディスクデバイスコントローラモデルを構成します。
• 書き込み性能（読み取り性能ではなく）の点で、最適なSSDモデルを使用して、書き込み集約型I/Oモデルを使用します。
• vSAN デフォルトのストレージ ポリシーでストライプを使用します。
• mirror-1 の故障最小保護を使用します。
• オートバランスを有効にします。スタンドアロン クラスタでは障害ドメインは必要ありません。
• vSANクラスタの健全性と容量を定期的に監視します。
• 管理VMにNFSまたはその他の共有ストレージデータストアを使用して、PKSのみにvSANを使用可能な状態にします。

3.3 論理ネットワークアーキテクチャ

Streaming Data Platform アーキテクチャでは、次のネットワークレベルの構成を利用できます。

• vCenter分散スイッチ
• NSX-T ソフトウェア定義ネットワーク(SDN)

3.3.1 vCenter分散スイッチ構成のレビュー

このセクションでは、ノードごとに4つの物理ネットワークインターフェースを使用する場合の例とベストプラクティスを説明します。この例の図については、図6を参照してください。

図 7 は、vCenter for Streaming Data Platform で異なるトラフィック タイプを分離して分散する方法の例を示しています。

分散型スイッチのハイライトとベストプラクティスには、以下のようなものがあります。

• DVS 設定でネットワーク I/O 制御を無効にします。
  • このアクションにより、vSAN のスループットが最大化され、ポートグループでの事前に制限された帯域幅を回避することができます。
  • 管理には低帯域幅が必要です。
  • VMotion トラフィックは時折発生し、連続的ではありません。
  • vSAN トラフィックが最も集中します。
• LACPは物理スイッチで定義されているため、この制御は必要ありません。
  • この属性は、DVSではlag1として設定されています。
  • この設定では、ネットワーク I/O 制御は必要ありません。
• DVS の詳細設定を設定します。
  • LLDP（Link Layer Discovery Protocol）動作モードを Both に設定します。
  • マルチキャストフィルタリングモードを必要な規格に合わせて設定します。
• 各ポートグループの VLAN 設定とアップリンクのチーミングを設定します。
• 各物理サーバに最低4つの10/25 GbEネットワークインタフェースがあることを確認します。
• 以下の2つのペアで冗長性を確保します。
  • NSX-T オーバーレイ ESXI ホスト ネットワーク用の 1 つの NIC ペア (vmnic2 と vmnic3)
  • 他のサービス: vMotion、vSAN、Edge、およびオーバーレイVMネットワークトラフィック(vmnic0とvmnic1)用の1つのNICペア
• vSANは前提条件として冗長性が必要です。

3.3.2 NSX-T ソフトウェア定義ネットワーク

このセクションでは、NSX-T のソフトウェア定義ネットワーク (SDN) の概念と構成について説明します。

3.3.2.1 NSX-Tのコンセプト

NSX-Tは、従来のNSX-Vに代わるVMware製品です。

• これは、Geneve ユニバーサル トンネリング カプセル化プロトコルに基づいています。L2 by L3 のカプセル化方式を採用しています。
• NSX-Tの現在のバージョンは2.5.1（2019年12月現在）です。
  • MTUの最小値は1600です。推奨値は、Top-Of-Rackスイッチがサポートしている場合は9000です。
  • Geneve ネットワークは、NSX-T の命名法ではオーバーレイネットワークに相当します。
• エッジVMクラスタは、顧客ネットワークの外部トラフィックへのアップリンクトラフィックを管理します。

3.3.2.2 PKSのコンセプト

PKSには以下の点が当てはまります。

• BGPが必要なレイヤ3スイッチ
• T0ルータ
  • 物理スイッチのルーティング通信を管理する
  • BGP設定が必要
  • K8のパブリックIPルートを外部に配布する
• T1 ルーター
  • すべてのESXiホストに分散
  • PKSは、固有のT0とリンクしたT1のみを作成する
• NSX-Tでは、Streaming Data Platformサービスを公開するために、サブネットIP範囲（/24サブネット、フローティングIPプール）が必要です。
• PKSでサポートされている現在のT0アクティブパッシブクラスタ構成

3.3.2.3 PKSのNSX-T構成

以下の点は、PKS用のNSX-Tの構成に当てはまります。

• FLIP（フローティングIPプール）
  • Streaming Data Platformサービスを外部に公開するために必要です（Pravega Controller、ingress、Grafana、またはFlinkなど）。
  • スケールアップしてより多くのPKSクラスタを作成し、独立したStreaming Data Platformインスタンスを取得します。PKS SDP クラスターの数は、物理ノードの総数と各 PKS クラスターに必要なサイズによって異なります。
  • PKSクラスタにワーカー（VMS）を追加して、1つのStreaming Data Platform PKSクラスタ内でより多くのK8ノードを取得できるようにスケールアウトします。例：1つのStreaming Data Platformクラスタは、マスター3人、ワーカー5人から、1クラスタあたりのワーカー数を30～40人にまで増やすことができます。
• IPプール（VTEP、オーバーレイNSX-Tリソース内部通信）。
  • 例：172.16.104.0/24 on VLAN 104
• IPAM IPプール（ポッドとPKSノードの内部IP)
  • ノードのIPAM範囲：172.32.0.0/16
  • ポッドのIPAM範囲：172.28.0.0/14
• ノードのオーバーレイ構成
  • vmnic2 と vmnic3 はオーバーレイプロトコル専用で、NSX-T はこれらのインターフェイスを完全に制御する
  • ソフトLACPに近いロードバランスとして論理的に設定されている
  • PKS/K8s Streaming Data Platformポッドの完全な内部通信を提供
  • エッジオーバーレイの通信はvCenter DVSで行う（それらはVMである)
• プロファイル
  • アップリンクとオーバーレイアセットの設定定義
  • エッジクラスタ-VMの健全性のための良い構成キー
• 以下に登録されているvCenter
  • すべてのNSX-Tコンポーネントとの通信
  • 各ESXiにカーネルモジュールをインストールして、NICを直接管理する
• T0ルータ構成の考慮事項（PKSに必要なのは1つだけ）
  • NAT：すべての管理Pivotal IPを手動で追加する必要があります。
    • ＤＮＡＴとＳＮＡＴ
    • s-pks-mgmt スイッチは手動で作成されました。
      Pivotal やその他の管理用 VM 用に、FLIP の最初の 7 つの IP を予約します。
      例。
      • OpsMan: 172.16.0.2
      • Boshd: 172.16.0.3
      • PKS: 172.16.0.4
      • Harbor: 172.16.0.5
      • linux-Jumpserver: 172.16.0.6
      • DNS-Internal: 172.16.0.7
• BGP（スイッチ構成例）
  • 172.16.105.20
  • 172.16.105.21
  • 近隣環境：172.16.105.2、172.16.105.3（物理スイッチ)
    • 記載されている経路分布T0
    • 前提条件としてファイアウォールを無効にする
    • 内部OpsMan、PKS、および管理用IPのT0 NAT
    • NATヘアーピンニング
    • T0 NATとルーティングパスの分配
    • ヘアピニング。ソースとデスティネーションがNSX-T NATの後ろにある

• 管理用T1分散ルータ: ls-pks-mgmt
  • 手動操作。重要な管理VMで使用される最初の7つのIPのみ
  • ルートポートを作成。172.16.0.1
  • サービスルータは必要ありません。エッジクラスタとの関連付けは必要ありません。
  • ルート配信を有効にする
• ＰＫＳで作成したＴ０にリンクしたＴ１自動ルータ
  • API通信でPKSで管理
  • PKSが扱うすべてのNSX-Tオブジェクト
    • ハイライト。PKSクラスタの削除は、NSX-Tで作成されたすべてのオブジェクトを解放するために、PKS CLIから実行する必要があります。
    •  https://code.vmware.com/apis/696/nsx-t
    • 1つのオブジェクトを手動で削除する必要がある場合は、APIコールを使用します。
    • 例: DELETE /api/v1/logical-router-ports/<logical-router-port-id>

curl -k -u admin:P@ssw0rd -X DELETE ‘https://172.16.101.61/api/v1/logicalrouter-ports/e78a357e-274c-428a-9e4d-1d660b196804’ -H “X-Allow-Overwrite:
true”

• 免許証。60日間の評価
• OpsManとPKSで必要な証明書の生成、NSX-Tで以下のように生成して登録します。

OpsManおよびPKS用のCA.crtおよびPKS-superuser証明書

詳しくは以下をご覧ください：https://docs.vmware.com/en/VMware-EnterprisePKS/1.4/vmware-enterprise-pks-14/GUID-generate-nsx-ca-cert-24.html

3.4 論理インフラストラクチャのオーバーヘッドに関する考慮事項

仮想化レイヤ、特にＰＫＳは、無視できないほどのリソースオーバーヘッドを導入します。SDPではこれらのリソースを考慮することができないため、これらのオーバーヘッドを正確に推定する必要があります。

表3　最小限と小規模の展開

表4　中規模および大規模な展開

注：考慮すべき重要なポイントの1つは、中/大規模クラスタサイズの場合、NSX-Tエッジノードの数を2倍にすることです。目的は、クラスタがインバウンド/アウトバウンドのトラフィック容量を2倍にできるようにすることです。また、NSX-T Edge Nodesは、NSX-T Edge Nodesが動作する物理サーバの25GbEポートにマップされることを想定しています。また、NSX-Tエッジノードにアンチアフィニティポリシーを設定して、物理サーバに分散させることも重要です。

もう一つ考慮しなければならないのは、vSANは物理サーバごとに一定量の物理メモリを消費するということです。vSANのメモリ消費量を以下のように考えてみましょう。

表5　vSAN オーバーヘッド

最後の検討事項として、追加のネットワーク問題を回避するために、SDP用の内部DNSサーバーをセットアップすることが重要です。また、運用やトラブルシューティングのためにVMを準備しておくことも推奨されます。

表6　DNS と Jumpbox のオーバーヘッド

4 物理的インフラ

ここでは、Streaming Data Platformの推奨物理インフラについて説明します。

4.1 サーバー

このソリューションでは、2つの物理アーキテクチャのオプションを提供しています。

• 従来のモデル：PowerEdge R640シリーズの使用を推奨
• Dell EMC VxRailモデル：VxRail Hyperconvergedインフラストラクチャを使用しています。このモデルでは、Bookkeeper on Bosh の展開はサポートされていません。

どちらのモデルも、4つの異なる展開オプション（最小/小/中/大）をサポートしています

表7　クラスターサイズ

4.1.1 従来のモデル

コンピュートノードはESXiバージョン6.7.0u3以上で動作しています。各ノードは、Dell EMC PowerEdge™ R640 サーバを使用して構築されています。詳細については、表 8 と図 8 を参照してください。

表8  従来のモデル：コンピュートノード

4.2 スイッチ

Streaming Data Platformには、2台のトップオブラックスイッチが必要です。Dell EMC PowerSwitch S5200-ONシリーズスイッチを推奨します。デュアルスピード10/25 GbE（SFP+/SFP28）ポートと40/100 GbEアップリンクを提供します。

サーバー数や将来の成長要件に応じて、以下のスイッチを推奨します。

• 成長が期待できない4台または6台のサーバーを持つ最小・小規模クラスタ：2台のPowerSwitch S5224-ON
• 12台のサーバーを搭載した中規模クラスター：2台のPowerSwitch S5248-ON
• 24台のサーバを搭載した大規模クラスタ：2台のPowerSwitch S5296-ON

トラフィックは以下のように2つのスイッチに分散させることができます。

• 内部トラフィック：管理およびNSX-Tオーバーレイ通信
• 外部トラフィック：アップリンクネットワーク（NSX-T）と長期ストレージトラフィック
• vCenterネイティブ・トラフィック: Isilonストレージ上のvSAN、vMotion、vCenterデータストア

注：アップリンクポートのMTUは、スイッチ（内部スイッチ、カスタマスイッチ）で9216に設定する必要があります。

4.3 Long-Term Storage (LTS)

Streaming Data Platform 1.1では、新しいストレージオプションが導入されました。以前のSDPリリースではLTSとしてIsilonをサポートしていましたが、SDP 1.1ではLTSとしてECSをサポートしています。これにより、ECS S3バケットをPravega長期ストレージと分析プロジェクトのストレージに使用できるようになります。この判断はインストール時に行う必要があります。同じSDPインスタンスで両方のストレージオプションを同時に使用することはできません。一方のストレージオプションから他方のストレージオプションへの移行はサポートされていないことに注意してください。

4.3.1 Isilon

Streaming Data Platformは、NFSv4/v3をLTSとして搭載したIsilonシステムをサポートし、長期・永続的なストレージを実現します。

H600、H500、H5600、H400、A200、またはA2000モデルがサポートされています。長期的に予想されるデータの増加に応じて、適切なIsilonモデルを慎重に選択してください。

Isilon構成のハイライトと推奨事項は以下の通りです。

• IsilonシステムではNFSv4が有効になっています。
• Isilonストレージは、他のデータセンターリソースと共有することができ、Streaming Data Platform専用にする必要はありません。
• Isilonストレージを使用して、管理VM、vCenter VM、バックアップ用のNFSデータストアをvCenterに提供することができます。各ノードを構成し、DRSでデータストアクラスタを作成します。この実践により、HA、冗長性、スループットの向上を実現します。
• 最良のオプションは、IsilonのデータネットワークインターフェースをStreaming Data Platformインフラストラクチャのスイッチに接続することです。このオプションが不可能な場合は、ネットワークHOPの数を最小にして、最高のレイテンシを得るようにしてください。
• ベストプラクティスは、Isilonネットワークインターフェイスのデータポートに対してスイッチ上でLACPを構成することですが、特定の構成に依存します。
• 各 Streaming Data Platformsポッドは、vCenter DVSアップリンクポートグループを使用して、仮想T0ルータを使用してNSX-TエッジVMを介してIsilonストレージに接続します。

4.3.2 ECS S3 Buckets

Streaming Data Platformは、長期・永続的なストレージを実現するLTSとしてS3バケットを搭載したECSシステムをサポートしています。

ECS構成のハイライトと考察

• ECS 3.4 をサポートしています。
• SDP 1.1はS3ヘッドのみをサポートしています（NFSヘッドへのアクセスはできません）。
• アクセスキーセキュリティのみサポートされています (Pravega と Analytic Projects の両方)。
  • SDP 1.1 では IAM はサポートされていません。
• GEOレプリケーションはサポートされていません。
  • バケットへのアクセスはすべて、プライマリ所有サイトを経由する必要があります。
• ロードバランサーはサポートされていますが、SDPの一部ではありません。
  • Pravega は ECS Smart Client を使用しているため、アプリケーション層でロードバランシングが可能です。
  • Flinkはアプリケーション層でのロードバランシングはできません。
• HTTPとHTTPSの両方の通信がサポートされています。
  • また、カスタムトラスト（自己署名証明書など）にも対応しています。