G業界における仮想化ハイパーコンバージェンスアーキテクチャの実践に関する簡単な議論

[[415486]]

この記事は張志鋒が執筆したWeChatパブリックアカウント「独特の職人技と効果」から転載したものです。この記事を転載する場合は、Jingxinduyun Weimiaoweixiaoの公式アカウントにご連絡ください。

1.概要

G銀行は、インフラリソースをさらに統合して統一的かつ標準化された管理を実現するために、2016年に支店に適したハイパーコンバージドインフラソリューションを選択し、分散展開方式でプライベートクラウド支店リソースプールを構築しました。数千のシステムが稼働しており、支店のローカル業務システムを含む多数の本番システムの迅速な導入と安定した運用をサポートしています。各支店の主要ITインフラ環境となり、集中的なリソース管理、柔軟な割り当て、効率的な展開という構築目標を達成しました。

2. G-Bank ハイパーコンバージド インフラストラクチャ

1. ハイパーコンバージドインフラストラクチャを採用する理由

ハイパーコンバージド インフラストラクチャ (HCI) は、ストレージ、コンピューティング、ネットワーク、管理など、従来のデータセンターのすべての要素を組み合わせた統合されたソフトウェア定義システムです。仮想化されたリソース プールの形式では、各リソース ノードはコンピューティング、ネットワーク、ストレージ、仮想化リソースを備えているだけでなく、ネットワークを介して複数のノードを集約し、管理用の統合リソース スケジューリング プラットフォームを備え、モジュール式のシームレスな水平拡張を実現できます。

従来の X86 サーバーと集中型ストレージで構成される仮想化プラットフォームと比較して、ハイパーコンバージド アーキテクチャで展開されたリソース プールには、展開が速く、コストが低く、コンピューティング リソースの無駄が少なく、コンピューター ルームのスペースを節約できるという利点があります。

仮想化されたハイパーコンバージド アーキテクチャにより、コンピューティング リソースの柔軟性のない割り当てやシステムの可用性の低さなど、G 銀行支店のデータ センターの問題点を解決できました。優れた水平拡張能力により、変化し続ける銀行業務の急速な成長にも十分対応でき、建設の初期段階で多額の資本投資を必要としません。

2. ネットワーキング

信頼性を考慮して、管理プレーン、ビジネス プレーン、およびストレージ プレーンは 2 つのネットワーク ポートによってバインドされ、2 つのアクセス スイッチへのデュアル アップリンクが設定されます。独立した仮想スイッチを使用して仮想化プラットフォーム内で異なるネットワーク プレーンが構成され、VLAN によって分離されます。

3. 分散ストレージシナリオにおけるデータ保護

ハイパーコンバージド アーキテクチャでは、各ハイパーコンバージド ノードはコンピューティング ノードとストレージ ノードの両方になります。この分散機能とデータ保護メカニズムを組み合わせることで、分散ストレージはハイパーコンバージド アーキテクチャに基づいて、簡単に拡張可能で信頼性の高いストレージ リソース プールを構築できるようになります。

ストレージ ユーザーにとって、ストレージ システムの信頼性は日常的な話題です。従来のストレージでは、RAID は主に高いデータ信頼性を確保するために使用されます。分散ストレージ システムでは、複数のコピーと EC (消去コード) がより一般的なデータ保護方法です。

では、マルチコピーとは何でしょうか? EC をどう理解するか?それらの違いと利点は何ですか?

簡単に言えば、複数のコピーとは、データが複数の分散システムのストレージ ノードに重複して書き込まれることを意味します。このマルチコピー データ保護方法は実装が簡単で、信頼性も非常に高いです。レプリカが配置されているすべてのストレージ ノードに障害が発生しない限り、ビジネスには影響はありません。しかし、欠点は、複数のコピーのスペース利用率が低いことです。

3つのコピーを例に挙げてみましょう（下の図を参照）

サーバー A の物理ディスク A 上のデータ ブロック P1 の場合、システムはそのデータをサーバー B の物理ディスク B に P1''、サーバー C の物理ディスク C に P1' としてバックアップします。P1、P1'、および P1'' を合わせて、同じデータ ブロックの 3 つのコピーを構成します。 P1 が配置されている物理ディスクに障害が発生した場合でも、P1' と P1'' はストレージ サービスを引き続き提供し、ビジネスに影響が及ばないようにすることができます。

さらに、データ再構築メカニズムにより、ストレージ容量が十分な場合、単一または複数のストレージ ノードに障害が発生した場合でも、同じメタデータのコピーが 3 つ存在するように、それらのノードを迅速に再構築できます。概略図は以下のとおりです。

ただし、3 つのコピー メカニズムは、データの信頼性と一貫性が高いという点で優れたパフォーマンスを発揮しますが、ストレージ スペースの使用率はわずか 33% であり、これもエンタープライズ ユーザーのストレージ コストの増加につながります。

4.EC

EC は、元のデータの n 個のコピーに m 個のデータのコピーを追加し、n+m 個のコピーのうち任意の n 個のデータのコピーを通じて元のデータを復元できるデータ保護技術です。 n+m 個のデータのコピーがストレージ システムの異なるノードに分散されている場合、m 個以下のノードのいずれかに障害が発生した場合 (m 個のデータのコピーが無効になった場合)、残りのデータを通じて元のデータを復元できるため、業務に影響を与えないという目的を達成できます。 EC アルゴリズムは柔軟に構成できます。たとえば、システムが 2 つのノードの同時障害をサポートする必要がある場合、m = 2 で十分です。スペースの利用率という点では、EC は複数のコピーよりも優れています。 4+2を例にとると、スペース使用率は4/(4+2)=67%となります。この使用率は、3 つのコピーの 2 倍に相当します。信頼性の面では、3 つのレプリカと同様に、2 つのノードの同時障害をサポートできます。ただし、EC4+2 を例にとると、このデータ保護メカニズムはハイパーコンバージドノードの拡張方法を制限し、1 回あたりの最小拡張回数は 4+2=6 になります。ハイパーコンバージドアーキテクチャが誇る柔軟な拡張機能の一部が失われています。

最終的に、銀行 G は、ハイパーコンバージド アーキテクチャの柔軟な水平拡張機能を維持しながら、金融業界のデータ信頼性要件に基づいて、より高いデータ信頼性と強力な一貫性を備えた 3 つのコピー メカニズムを選択しました。

5.Xen または KVM

設立当初、G 銀行のハイパーコンバージド アーキテクチャ リソース プールは、技術的に成熟した Xen アーキテクチャ仮想化テクノロジーを選択しました。 KVM テクノロジーが成熟するにつれ、2020 年に Xen アーキテクチャから KVM アーキテクチャへのアップグレードが最終的に選択されました。この 2 つの利点と欠点は何でしょうか。

まず、仮想化テクノロジーとは何かを理解する必要があります。ハイパーバイザーは、基盤となる物理サーバーとオペレーティング システムの間で実行される中間ソフトウェア レイヤーであり、複数のオペレーティング システムとアプリケーションがハードウェアを共有できるようにします。仮想マシンモニターなので、VMM（仮想マシンモニター）とも呼ばれます。

ハイパーバイザーは仮想環境で実行されるオペレーティング システムです。ディスクやメモリを含むサーバー上のすべての物理デバイスにアクセスできます。ハイパーバイザーは、これらのハードウェア リソースへのアクセスを調整するだけでなく、仮想マシン間の保護も強化します。サーバーが起動してハイパーバイザーを実行すると、すべての仮想マシン クライアントのオペレーティング システムがロードされ、各仮想マシンに適切な量のメモリ、CPU、ネットワーク、ディスクが割り当てられます。ハイパーバイザーが果たす役割や機能に応じて、さまざまな仮想化テクノロジが生まれています。 Xen と KVM は、それぞれ準仮想化と完全仮想化という 2 つの仮想化テクノロジを代表すると言えます。

完全仮想化（左）と準仮想化（右）

完全仮想化: 仮想マシンは基盤となるハードウェアを完全にシミュレートします。 Linux システムは、カーネル レベルで仮想化を直接サポートします。ハイパーバイザーを適応させる際にオペレーティング システムを変更する必要はありません。完全に仮想化された仮想プラットフォームでは、ゲスト OS (クライアント オペレーティング システム、つまり仮想マシン オペレーティング システム) はそれが仮想マシンであることを認識しません。コンピュータの物理ハードウェアデバイス上で実行されている HostOS (ホスト オペレーティング システム) であると考えます。完全に仮想化されたハイパーバイザーは、OS が操作できる CPU、メモリ、周辺機器などの物理デバイスを仮想 CPU、仮想メモリ、仮想周辺機器などの仮想デバイスに論理的に抽象化し、ゲスト OS に渡して操作および使用できるようにします。このようなゲスト OS は、基盤となるハードウェア プラットフォームを独自のものとして扱いますが、実際には、これらはすべて、ゲスト OS 用にハイパーバイザーによって作成された幻想です。

KVM は、ハードウェア支援による完全仮想化テクノロジーとして、主に KVM ドライバーと Qemu の 2 つの部分で構成されます。 KVM ドライバーは Linux システム (Intel-VT または AMD-V) に直接統合されており、主に仮想マシンの作成、CPU およびメモリの割り当てなどを担当します。

ハードウェア支援による完全仮想化テクノロジーとして、プロセッサは仮想化サポートを直接提供します (プロセッサは複数のオペレーティング システムに対して仮想化できます)。メモリは kvm を通じて仮想化できます (Linux 機能の助けを借りて)。最後に、I/O はわずかに変更された QEMU プロセス (各ゲスト OS プロセスのコピーを実行する) を介して仮想化されます。

KVM は、既存のカーネル モードに加えて、クライアント オペレーティング システム コードの一部を実行するために使用されるクライアント モードという新しいプロセス モードを Linux に導入します。カーネル モードはコード実行の特権モードを指し、ユーザー モードは非特権モード (カーネル外で実行されるプログラム用) を指します。操作の内容や目的に応じて、さまざまな実行モードを定義できます。クライアント モードの目的は、クライアント オペレーティング システム コード、つまり仮想マシン オペレーティング システムのコード (ただし、非 I/O コードのみ) を実行することです。ゲスト モードには 2 つの標準モードがあるため、ゲスト オペレーティング システムは、ゲスト モードで実行されているときは標準カーネルをサポートし、ユーザー モードで実行されているときは独自のカーネルとユーザー スペース アプリケーションをサポートできます。ゲスト オペレーティング システムのユーザー モードを使用して、個別に管理される I/O 操作を実行できます。

ゲスト オペレーティング システム上で I/O を実行する機能は、QEMU によって提供されます。 QEMU は、完全な PC 環境 (ディスク、グラフィック アダプター、ネットワーク デバイスを含む) の仮想化を可能にするプラットフォーム仮想化ソリューションです。ゲスト オペレーティング システムによって生成されたすべての I/O 要求はインターセプトされ、QEMU プロセスによってエミュレートされたユーザー モードに再送信されます。

メモリ仮想化に関しては、KVM は単なる単純な仮想化モジュールであるため、メモリ管理は自己実装されておらず、メモリ管理を実装するには Linux カーネルに依存する必要があります。 KVM は Linux でサポートされている任意のストレージを使用でき、ドライバーの実装では Linux カーネルを直接使用してハードウェアを駆動します。

準仮想化: 準仮想化 VMM で GuestOS を実行するには、GuestOS のカーネル コードに特定の変更を加える必要があります。カーネルを変更すると、GuestOS もそれが仮想マシンであることを認識します。したがって、カーネル状態命令と機密命令を適切に識別して処理できますが、ゲストOS イメージ ファイルが汎用的ではないという欠点があります。

XEN は、ハイパーバイザー、ドメイン 0、ドメイン U という 3 つの基本コンポーネントで構成されています。ハイパーバイザーはハードウェア上で実行され、すべてのオペレーティング システムをホストし、CPU とメモリのスケジューリングを提供します。 Domain0 は管理者であり、主に IO デバイスの仮想化を担当します。 DomainU は XEN の実際の仮想クライアントであり、DomainU は完全仮想クライアントと半仮想クライアントの 2 つのカテゴリに分かれています。後者は変更されたオペレーティング システム上で実行されます。

一般的に、Xen はコンピュータ ハードウェア上で直接実行され、オペレーティング システムを置き換えるソフトウェア レイヤーであり、これにより、複数のゲスト OS をホスト OS 上で同時に実行できるようになります。 KVM は HostOS (Linux) カーネルに組み込まれています。現在、主流の CPU は仮想化に対応しており、ハードウェア仮想化の条件も整っているため、KVM は市場のほとんどの CPU に適応できます。軽量の観点から見ると、KVM はより合理化されており、クライアント オペレーティング システムを変更する必要がなく、より柔軟で導入が容易です。バージョン アップグレードが必要な場合、Xen アーキテクチャでは、ホストの基盤となる OS にパッチを適用し、カーネル全体を再コンパイルする必要があることがよくあります。リスクは想像できます。さらに、仮想化オープンソースアーキテクチャとして、KVM はより完全なエコシステムを備えています。そのため、銀行 G は最終的に Xen アーキテクチャから KVM 仮想化アーキテクチャへのアップグレードを選択しました。

3. ハイパーコンバージドアーキテクチャの今後の展開

G 銀行支店のハイパーコンバージド インフラストラクチャ リソース プールは、支店の運用システムに迅速な展開、柔軟な割り当て、高可用性のインフラストラクチャ サービス機能を提供することに注力しており、銀行全体のビジネス、特に支店のビジネスの急速な発展を強力にサポートします。インフラサービス機能の継続的な深化、構成の最適化、ハイパーコンバージドコンポーネントのアップグレードと反復、本社管理制御プラットフォームの包括的な交換とアップグレード、およびきめ細かい監視構築はすべて、G銀行のハイパーコンバージドアーキテクチャリソースプールの将来の開発方向になります。インフラサービス力の強化に注力するとともに、時代の変化に対応し、ハイパーコンバージェンスをベースとしたコンテナ仮想化展開適応力を培っていくことも今後の取り組みの方向性となります。