VMwareとKasten:Kubernetesと先端アプリケーションのためのデータ管理


Project Pacificでは、VMwareはKubernetesをvSphereに深く統合し、先端のアプリケーション開発と運用を可能にしました。Kubernetes専用に構築されたKasten K10は、アプリケーションのバックアップやモビリティを含む重要なデータ管理機能を提供します。Kastenは、VMwareのデータ管理デザイン・パートナーとして、企業のオペレーション・チームは、このクラウドネイティブ時代に成長するKubernetesアプリケーションをシームレスに保護することを提供します。

ここでは、データ管理の観点から先端アプリケーションがもたらす変化について説明し、ビルディングブロックに踏み込み、Kasten K10がvSphere、CNS(Cloud Native Storage)、TKG(Tanzu Kubernetes Grid)などのVMwareポートフォリオとどのように統合し、アプリケーションのバックアップとモビリティを提供するのかを説明します。

先端アプリケーションのためのカンブリア紀時代

私たちは、先端アプリケーションのためのカンブリア紀の瞬間を目撃しています。IDCは、企業が2019年から24年の間にクラウド・ネイティブのツールや手法を使用して5億のアプリを構築すると予測しているます(IDC Futurescape、2018年)。これは、過去40年間に構築されたアプリの総数に相当します。Kubernetesは、オーケストレーションの観点からだけでなく、組織がこれらのクラウド・ネイティブアプリケーションを構築、実行、管理できるようにする拡張型エコシステムを立ち上げています。この堅牢なエコシステムの一例として、クラウドネイティブ・コンピューティング・ファウンデーション(CNCF)にはすでに500社以上のメンバー企業があり、そのリストは現在も増え続けています。

先端アプリケーションにおけるステートの取り扱い

ショッピングカートの追跡、IoTデバイスのヘルス状態、財務記録など、状態を維持することは、ほとんどのアプリケーションで必須です。従来のアプリケーションでは、ステートフルなニーズに対応するために、モノリシックなリレーショナル・データベースを使用していました。

しかし、先端アプリケーションの仕上げは、クラウドネイティブ時代以前に構築されたものとはかなり異なることがわかります。主な違いのいくつかには、同じアプリケーションの一部として複数のステートフルサービスを持つ、より小さなマイクロサービスを使用していることがあります。基底となるステートフル・サービスの選択は、ワークロードとビジネスロジックに基づいて行われます。

マイクロサービスベースのアプリケーションでは、複数言語の永続化(polyglot persistence)が当たり前になっています。最近のデータベースには、SQLデータベース(MySQL, PostgreSQLなど)、NoSQLデータベース(Redis, Cassandra, MongoDBなど)、メッセージキュー(Kafka, RabbitMQなど)、オブジェクトストア(Amazon S3, Google Cloud Storage, Minioなど)などがあります。

注:ポリグロット・パーシステンス(polyglot persistence):データの特性ごとに適材適所のデータベースの種類を使うコンセプト

VMwareのKubernetes採用

VMwareはKubernetes を vSphere に深く統合して、企業が vSphere 上でこれらの先端アプリケーションの開発と運用を行う際に役立つ、いくつかのワクワクするな取り組みがあります。 Project Pacific では、開発者は Kubernetes ネイティブ API を使用して、コンピュート、ネットワーキング、ストレージなどのリソースにアクセスすることができます。IT 運用チームは引き続き vCenterを使用して、開発とスケーラブルな運用のためにこれらのリソースを迅速にプロビジョニングし、提供します。

Kubernetes関連の取り組みはいくつかありますが、この中でもう一つのエクサイトなアップデートが、vSphere v6.7 Update 3リリースで導入されたVMware Cloud Native Storage (CNS)です。CNSは、vSANを含むブロックとファイルにまたがるvSphere全体のKubernetesストレージ・プラットフォームを提供します。ここでは、VMware First Class Disks(FCD)がKubernetesアプリケーションのライフサイクルに適したブロックストレージを提供し、特定のVMインスタンスに縛られません。これらの取り組みは、Kubernetes 環境で状態(ステート)を扱う構成に役立ちます。

Kubernetesのデータ管理の課題

これらのビルディング・ブロックは、先端のアプリケーションがこのポリグロット環境でステートを処理するための基礎を提供しますが、バックアップやアプリケーションのモビリティを含むデータ管理など、二次運用ニーズについても考える必要があります。Kubernetesアプリケーションのバックアップをサポートすることは、クラウドネイティブ技術と運用が提供するアジリティとスケールメリットのすべてから恩恵を受けようとしている組織にとって、依然として重要なニーズであることに変わりはありません。Kubernetesの世界にはさまざまな要件や考慮事項があり、ハイパーバイザー環境で動作するように作成されたレガシーバック・アップソリューションは、以下のような課題に直面しています。

アプリケーションの可視化:
Kubernetes上の先端アプリケーションでは、サーバやVMへのアプリケーションのマッピングはありません。Kubernetesは、フォールトトレランスとパフォーマンスのために、アプリケーションコンポーネントを複数のサーバ/ノードに分散させることができます。さらに、コンテナを動的に再スケジューリングしたり、異なるノードでスケーリングしたりすることで、高効率の負荷分散を実現することができます。その結果、ハイパーバイザ中心のバックアップソリューションでは、この分散された動的な環境でアプリケーション全体を保護することができなくなります。

クラウドネイティブのスケール:
スケールの観点から見たクラウド・ネイティブアプリケーションの要件は、従来のアプリケーションと比較して劇的に増加しています。その背景には、複数のマイクロサービス、アプリケーションコンポーネント(コンフィグマップ、シークレットなど)の爆発的な増加、動的なオートスケーリング(クラスタやアプリケーション)、ポリグロット永続性(1つのクラウドネイティブアプリケーションで使用される複数のデータベースなど)などがあります。

Kubernetesデータ管理の原則

このKubernetesネイティブ時代の先端アプリケーションを保護するためには、優れたデータ管理ソリューションは、上記の課題を克服するだけでなく、以下の原則を遵守しなければなりません。

DevOpsとシフトレフト :
Kubernetと並行して採用されたDevOpsの理念は、インフラとディプロイの両方の制御を開発者に譲る(「シフトレフト」と呼ばれています)ものです。開発者は、アプリケーションコンポーネントとインフラストラクチャ要件(ストレージやロードバランサーなど)の両方をコードとして定義します。これらのプログラム的な要求は、CI/CD パイプラインを介して、大規模な変更管理プロセスなしで、動的にプロビジョニングされます。この環境では、アプリケーションを運用単位として扱うべきです。このアプローチは、クラウドネイティブ環境における運用チームと開発チームのニーズのバランスをとるものです。アプリケーションは、開発者と運用者の両方が最終的に関心を持つものです。

最新のデータベース :
先に説明したように、同じアプリケーション内で複数のデータサービス(MongoDB、MySQL、Cassandraなど)を使用するポリグロット・パーシステンスの台頭は、Kubernetesの成長と一致しています。これらのワークロードのバックアップは、ワークロードの自動発見のためにはKubernetesに対して統合されている必要があります。ワークロードの知識があれば、バックアップ・ソリューションは、アプリケーションの要件に最も適したキャプチャプリミティブ(1つ以上のボリューム・スナップショット、アプリケーションの一貫性のあるバックアップ、論理ダンプなど)を選択できるようになります。

選択の自由:
先端のクラウドネイティブバック・アップソリューションは、多様なインフラ・ストラクチャとKubernetes環境を持つクラスター、リージョン、さらにはクラウド間のアプリケーションの移植性を可能にする機能を提供する必要があります。Kubernetesのバージョンは通常3カ月ごとにリリースされており、さらに、さまざまなベンダーから利用可能ないくつかのディストリビューションがあります(例:VMwareのTanzu Kubernetes Grid(TKG)、AWSのEKS、AzureのAKS、Red HatのOpenShift)。バックアップソリューションは、アプリケーションのリストアや移行を可能にし、特定のインフラベンダーやKubernetesのバージョンに縛られないようにする必要があります。

Kasten K10とVMwareでデータ管理を解決

Kasten K10データ管理ソフトウェアプラットフォームは、Kubernetes専用に構築されています。データ管理のVMwareデザイン・パートナーであるK10は、TKGや他のKubernetesディストリビューションにまたがってvSphereとシームレスに導入することができます。K10のアプリケーション中心のアプローチとリレーショナル・データベースやNoSQLデータベース、VMware Cloud Native Storage (CNS)を含むストレージシステムとの強度な統合により、Kubernetesアプリケーション全体のバックアップ/リストアとモビリティを実現します。運用のシンプルさを核としたK10は、Kubernetesアプリケーションのモビリティとバックアップを非常に簡単に実現できます。

Kasten K10でFCDをネイティブサポート:
KastenはVMwareと緊密に協力して、K10でFirst Class Disks (FCD)のネイティブサポートを追加しました。FCDは、Improved Virtual Disk (IVD)と呼ばれることもありますが、Kubernetes用に作成されたもので、独立したライフサイクル管理(作成や削除操作など)を可能にします。これまでの vSphere 仮想ディスクとは異なり、FCD は VM に関連付ける必要がなくなり、スナップショットやバックアップなどのアクションを FCD 上で独立して実行できるようになります。これらの FCD は、Kubernetes 用の新しい vSphere Container Storage Interface (CSI) プラグインによってプロビジョニングできます。FCD は、Kubernetes ベースのステートフル アプリケーションのストレージをプロビジョニングするためのパスフォワードであることを考えると、K10 の FCD 統合により、vSphere インスタンスに接続し、Kubernetes の vSphere CSI ドライバによってプロビジョニングされたすべての FCD を自動検出することができます。さらに、ネイティブ統合により、効率的なバックアップを作成する際に、変更ブロック追跡などの高度な機能を利用することができます。

Kasten K10とCNSの統合:
もう一つの統合ポイントは、vCenter Server上のVMwareのCloud Native Storage(CNS)です。CNSは、永続的なボリュームのプロビジョニングとライフサイクル・オペレーションを実装しています。Kasten K10とCNSの統合により、KubernetesがvSphereストレージのオンデマンド・プロビジョニングを実行できるようになり、管理者はvCenter内でこれらのプロビジョニングされたボリュームを確認することができるようになります。さらに、CNSは必要なレベルのサービスをディスクに保証するためのストレージポリシーベース管理とのインターフェイスします。

Kasten K10とTKGの統合:
下図は、統合のトップレベルの構成と、K10がバックアップとDR運用のために提供する機能を示しています。これには、クラスタ内のアプリケーションの自動検出や、ポリシーを使用した自動化の効率化が含まれます。また、これらのポリシーはアプリケーションがクラスタに導入されるとすぐに、事前に定義されたポリシーで自動的に保護されるように、将来を見越したものにすることもできます。これにより、バックアップのコンプライアンスが保証され、K10が提供する豊富なバックアップ一貫性オプションと相まって、VMwareのユーザは、Tanzu Kubernetes環境にも説得力のあるデータ管理ソリューションを提供することができます。

関連トピックス

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください