Pivotal CFのインフラストラクチャを展開する方法、または写真のパフペーストリーのレシピ

1年前、タスクはIT管理および監視システムのコンピテンシーセンターに「飛んで」いました。PivotalCloud Foundry製品（実際にはPaaSモデルの参照モデル）を展開します。 一言で言えば、 Pivotal Cloud Foundry （PCF）は、次のようなビジネス向けのターンキー商用ソリューションです。

• ハイブリッド環境またはマルチクラウド環境で実行されるプラットフォームが必要
• モノリシックアーキテクチャの使用からクラウドベースのスキームに移行したい。
• 初日から次世代のデジタルサービスを開始したい。
• すでにJavaまたはSpringを使用してマイクロサービスを展開しています。

この記事では、ベンダー製品を宣伝することも、「マイクロサービスについて説明する」ことも求めていません。 私の主な目標は、この種のソリューションの非標準構成でPCFクラウドプラットフォームのインフラストラクチャを展開した経験を共有することです。 この構成は、プロジェクトの開発者向けの環境を作成するタスクの過程で行われました。これは、偽りのない謙虚さなしに、デジタル変換と呼ばれていました。

Pivotalの「クック」

「ビジネス」から、マイクロサービスアーキテクチャを使用して製品を構築するというグローバルタスクが設定されました。 VMware仮想インフラストラクチャがIaaSとして選択されました。 PaaSとして-Pivotal Cloud Foundryプラットフォーム。

PCFを選択することで、特定のハイパーバイザーを参照せずにあらゆる規模のアプリケーションを作成するためのさまざまなプログラミング環境、データベース、およびサービスの既製セットを（開発者の意味で）ユーザーに提供することができました。 この柔軟性により、アプリケーションのビジネスロジックの構築に集中し、IaaSレベルの低レベルの機能に最小限アクセスできます。

ちょっとした歴史

仮想化ソフトウェアの最大の開発者であるVMwareは、Apache 2.0ライセンスの下でオープンソースのCloud Foundryハイブリッドクラウドプラットフォームを作成する最前線にいました。これは、ソフトウェアの継続的統合プロセスと継続的デリバリー（CI / CD）の品質を向上させるように設計されています。 2014年、非営利基金であるCloud Foundry Foundation（CFF）が、プロジェクトの共同開発、管理、およびプロモーションのための中立的なプラットフォームを作成した非営利組織であるLinux Foundationの支援の下に設立されました。 2015年、CFFコミュニティはCloud Foundryオープンソースプロジェクトに基づいてシステムを認定することを決定しました。 認定プログラムは、さまざまなクラウドサービスと企業の構内（オンプレミス）にあるシステム間でPaaSソリューションの移植性を確保するように設計されています。 現在、CFFには60を超える組織が含まれており、世界のテレコミュニケーションおよびエンジニアリングシステム市場のリーダーです。Cisco、Dell EMC、Hewlett Packard Enterprise、IBM、Pivo​​tal、SAP、VMware、Intelなど。

Pivotal Software、Inc. （Pivotal）-2013年以来、EMC CorporationとVMwareの別の部門は、幅広い革新的な開発を組み合わせて、使い慣れたターンキーアプリケーションの構成、管理、監視サービスを含むPivotal Cloud Foundry製品（オープンソースコードに基づく）を作成しました。

最も重要な「成分」

Cloud Foundryの哲学の基礎は、マイクロサービスアーキテクチャという用語です。

マイクロサービスアーキテクチャは、単一のアプリケーションを一連の小さなサービスとして表現する方法です。各サービスは独自のプロセスで動作し、軽量メカニズム（通常はHTTPプロトコル）を使用して他のサービスと通信します。 この用語は、「モノリシックアーキテクチャ」（全体として構築されたアプリケーション）と比較することで、最も簡単に説明できます。

従来のモノリシックアーキテクチャは、最新のクラウドには適していません。モノリス内のモジュールを個別にスケーリングすることはできず、一方のロジックの変更は、他方のコードに影響を与える傾向があります。 一方、マイクロサービスアーキテクチャでは、モジュールをさまざまなプログラミング言語で記述し、迅速に展開して簡単にスケーリングできます。これにより、アプリケーションの可用性係数が向上します。

Cloud Foundryのマイクロサービスアーキテクチャの開発の一環として、2つの主要な領域を区別できます。

• クラウドの中心は、さまざまなプラットフォーム（AWS、Azure、OpenStack、vSphere、vCloud、Google Compute Platform）をサポートする分散システムをデプロイおよび管理するためのオープンソースツールキットであるBOSHです。
• ライフサイクル管理（クラウドコントローラー）、パフォーマンス管理（ディエゴ）、ユーザー認証と承認（UAA）、メッセージング（NATS）、技術ステータスとヘルスの監視（ヘルスマネージャー）など、多くのシステムがアプリケーションのランタイム環境の正しい動作を担当します。 ）およびその他。

Cloud Foundryプラットフォームリリースに含まれるマイクロサービスのリストは膨大であるにもかかわらず、このリリースは、いわゆる「コンテナー」アプリケーション（アプリケーションコンテナー）をクラウドにデプロイおよび起動するために必要な最小限の基盤を提供します。

コンテナアプリケーションは、アプリケーションに必要なすべてのコンポーネントが含まれ、オペレーティングシステムに関係なく機能する、次のレベルの分離です。 コンテナ化されたアプリケーションの仮想化は、代替ソリューションと比較して、パフォーマンス、スケーラビリティ、密度、動的リソース管理、および管理の容易さを向上させます。

マイクロサービスの紹介はここで終わり、最も興味深い部分、インフラストラクチャの説明に進みます。

「調理」のために必要なのは...

VMwareクラスターのPCFプラットフォームのシステム要件を分析した後、いくつかの前提条件が形成されました。

• vSphere Inventory Hierarchyに従って、データセンターレベルの読み取り/書き込み権限が必要です。
• HTTPSを介したvCenterへのアクセスが必要です。
• TCP経由でESXiにポート443、902、903にアクセスする必要があります。
• vSphere DRS（分散リソーススケジューラ）オプションが有効になっている場合、自動化レベルを部分的に自動化または完全に自動化に設定する必要があります。

すでにこれらの要件に基づいて、PCFの展開には分離されたvCenterが必要であり、その結果、分離されたESXiホストが必要であることが明らかになりました。 そのようなセグメントを実装するために（読み取り、ハードウェアの保存）、アイデアはネストされた仮想化の概念を使用するというアイデアを思いつきました。

すぐに言ってやった！ これを実行するには、控えめな非伝統的なIaaSモデルを作成するために、VMwareとOpenStackの2つの仮想化環境に同時に実装されるパブリックCloud Technoserv Cloudが必要でした。 VMwareのコントロールパネルはvCloud Directorです。

すぐに予約します。実際には、このようなソリューションは製品版には行きませんが、テスト版または開発版として適合します。 さらに本文では、アーキテクチャ、インストールの主な機能と利点（または、欠点）について説明します。

同じ「レイヤーケーキ」

そのため、TS-Cloudでは、TS-CloudDev仮想データセンター（VDC）が次の特性で作成されました。

• メモリクォータ：750 GB
• vCPU速度：2.60 GHz
• CPUクォータ：314.60 GHz
• ディスククォータ：3474 GB
• VMクォータ：100
• ネットワーククォータ：10

Edge Gatewayを使用してターゲットクラスターの場合、4つの内部サブネットが作成されます。

1. 10.0.10.0/24-ネストされたESXiホストの管理ネットワークとして。
2. 10.0.11.0/24-ネストされたESXiホストにデプロイされた仮想マシンを移行するためのvMotionネットワークとして。
3. 192.168.63.192/26-内部ネットワークと統合するためのネットワークとして。
4. 10.10.0.0/16-PCFプラットフォームの展開ネットワークとして。

10.0.150.0/24サブネットはVDCの外部にあります。

Edge Gatewayコンポーネントの存在は、vCloud環境を使用する主な利点の1つであることは注目に値します。 DHCP、NAT、ファイアウォール、静的ルーティング、VPN、負荷分散などのネットワークサービスを提供するように構成できる仮想VDCネットワークルーターです。

ハードウェア構成に関しては、4つの同一のESXiホストと1つのvCenterサーバーに加えて、ストレージを提供するiSCSIイニシエーターとして機能する別の仮想マシンが作成されました。

下から見る：

「ex machina」を表示：

上面図：

...そして1週間後、1階の場所が終わったため、2番目のストレージがすぐに接続されました。

愛人メモ

展開プロセス中に、インフラストラクチャを準備するときに考慮しなければならない制約に必ず遭遇しました。

• Edge Gateway仮想ルーターは、最大10個のインターフェイスをサポートできます（上記のネットワーククォータを参照）。 インターフェイスは、外部ネットワークに接続されている場合はアップリンクとして、VDCネットワークに接続されている場合は内部インターフェイスとして分類できます。 Edge Gatewayを作成する場合、少なくとも1つのアップリンクを指定する必要があります。 ルーティングされたVDCネットワークが作成されると、内部インターフェイスが自動的に追加されます。

• VDCに割り当てられた合計ストレージサイズは、選択したモデル（割り当てモデル）に関係なく、 式に従って考慮されます。

  
  

  割り当てるストレージサイズ=仮想マシンに割り当てられた合計ストレージ+仮想マシンに割り当てられた合計メモリ（テンプレートに割り当てられたメモリを除く）+使用されるメディアストレージ

  したがって、合計ストレージサイズには、仮想マシンに割り当てられたメモリが含まれます。 この構成では、750 GBのRAMが割り当てられました。各ESXiの内部ストレージとして2 GB、vCenterの内部ストレージとして100 GB、仮想マシンストレージの内部ストレージとして16 GB。 つまり、合計750 + 2 * 4 + 100 + 16 + 2600 = 3474 GBがVDCに割り当てられます（上記のディスククォータを参照）。

  
  
• VDCの外部で無差別モードを有効にする必要があります。 これはVMwareネストの必須要件であり、次のように説明されています。
  VSS（vSphere標準スイッチ）とVDS（vSphere分散スイッチ）の両方は、vSphereプラットフォームが特定の仮想マシンに割り当てられているMACアドレスを既に知っているため、MAC学習機能を実装しません。 これは、宛先MACアドレスがESXi vmnic MACアドレス（pNIC）と一致する場合にのみ、仮想スイッチがネットワークパケットを仮想マシンに転送することを意味します。 ネストされた仮想化環境では、これらの仮想マシン宛てのネットワークパケットの宛先MACアドレスは、ネストされたESXi vmnic MACアドレスとは異なります。 この点で、無差別モードが有効になっていない場合、物理ESXiサーバーの仮想スイッチはパケットをドロップします。
• ファイルストレージ（元々NFSで使用されていた）は、プラットフォームの通常の動作に必要なディスクサブシステムのパフォーマンスを提供しません。 ブロックストレージが推奨されます（iSCSIの由来です）。

おわりに

結論として、Devブースでの組み込み仮想化の使用は、同時に許可されたため、主な利点の1つになったことに注目したいと思います。

• 分離されたデータストリームでエコシステムを作成します。
• インフラストラクチャの整合性を侵害しません。
• 開発者をスケーリングの問題から救います。
• 子仮想環境を完全に制御できます。