OpenStackはオープンソースのクラウドコンピューティングプラットフォームであり、そのアーキテクチャにはコンピュート、ストレージ、ネットワーキングサービスが含まれ、強力な仮想化機能と自動管理機能を提供します。OpenStackプラットフォームの高可用性を確保するためには、特定のアーキテクチャソリューションや技術的対策を採用する必要があります。この記事では、OpenStackの高可用性アーキテクチャの一般的なソリューションについて紹介します。
OpenStackの高可用性
高可用性を実現する方法を理解するには、どのサービスが障害にかかりやすいかを特定することが重要です。まず、OpenStackの構造について基本的な理解を深めましょう。
OpenStackは5つの主要コンポーネントで構成されています：コンピュート（Nova）、アイデンティティ管理（Keystone）、イメージ管理（Glance）、フロントエンド管理（Dashboard）、およびオブジェクトストレージ（Swift）。
Novaは、計算と制御を担当するコアコンポーネントです。nova-compute、nova-scheduler、nova-volume、nova-network、およびnova-apiなどのサービスが含まれます。他の多くの分散システムと同様に、OpenStackは制御ノードとコンピュートノードの2種類のノードに分けられます。制御ノードはnova-computeを除くすべてのサービスを提供します。これらのコンポーネントとサービスは個別にインストール可能であり、必要に応じて組み合わせを選択できます。
Nova-compute は各コンピュートノード上で動作します。ここではそれが信頼できるものと仮定します。そうでない場合は、障害切り替えのためにバックアップマシンを使用できます（ただし、各コンピュートノードに対してバックアップを構成することは、得られる利益に比べてコストが高すぎる可能性があります）。
コントロールノードの高可用性
コントロールノードの高可用性を確保することは主要な課題であり、異なるコンポーネントにはそれぞれ特定の可用性要件と解決策があります。
(1) 管理および制御の全システムを担当するコントロールノードが1つしかない場合、コントロールノードに障害が発生するとどうなりますか？
これは一般的な単一障害点（SPoF）の問題です。単一のマシンのみでは高可用性を実現することはできません。多くの場合、問題が発生した際に故障したマシンの処理を迅速に引き継ぐためのソリューションが設計されますが、これにはより高いコストがかかります。
シングルポイントの問題に対処するための一般的な解決策は、冗長化された装置やホットスタンバイを使用することです。ハードウェアの故障や人的ミスによっていつでも1つまたは複数のノードが障害になる可能性があり、保守やアップグレードの際に特定のノードを一時的に停止する必要があるため、信頼性の高いシステムは1つまたは複数のノードの停止に耐えることができなければなりません。
一般的な導入モードには、アクティブ・パッシブスタンバイモード、アクティブ・アクティブモード、およびクラスターモードが含まれます
(2) 冗長な制御ノードを構築する方法は？あるいは高信頼性の制御を実現する他の方法は何か？
多くの場合はアクティブ・パッシブモードを実装し、ハートビート機構や類似の方法を使用してバックアップを行い、障害切り替えによって高可用性を実現します。OpenStackは複数のコントロールノードを本質的にサポートしないため、Pacemakerでは各種サービスが各自のバックアップ、監視、および切り替えメカニズムを実装する必要があります。
コントロールノードが提供するサービスを詳しく見ると、主にnova-api、nova-network、nova-scheduler、nova-volume、およびGlance、Keystone、データベースのMySQLが含まれることが分かります。これらのサービスは個別に提供されます。nova-api、nova-network、Glanceは各コンピュートノード上で動作させることができ、RabbitMQはプライマリ・バックアップモードで運用可能であり、MySQLは冗長性のある高可用性クラスタを使用できます。
以下のセクションでは、これらのコンポーネントについて詳しく説明します。
主要コンポーネントの高可用性ソリューション
1) nova-api および nova-scheduler の高可用性
各コンピュートノードが独自のnova-apiおよびnova-schedulerを実行し、適切な動作のためのロードバランシングを確保します。この方法により、コントロールノードに障害が発生しても、コンピュートノード上のnova-apiおよび関連サービスは引き続き正常に機能します。
2) nova-volume の高可用性
現時点では、nova-volumeに完璧なHAソリューションは存在せず、さらなる作業が必要です。ただし、nova-volumeはiSCSIによって駆動されるため、DRBDとの統合やiSCSIに基づく高可用性ハードウェアソリューションを使用することで、高可用性を実現できます。
3) ネットワークサービスの高可用性（nova-network）
OpenStackはすでに複数の高可用性ネットワークソリューションを提供しています。「マルチホスト」オプションを使用して高可用性モードを有効にする方法が一般的に使用されています。その他の一般的なソリューションには、フェールオーバー、マルチNIC、ハードウェアゲートウェイ、Quantumが含まれます。
4) Glance と Keystone の高可用性
OpenStackのイメージはSwiftを使用して保存でき、Glanceは複数のホスト上で動作可能です。Pacemakerは、マルチノードクラスターの管理に強力な高可用性ソリューションを提供し、サービスの切り替えとフェールオーバーを実現します。また、CorosyncやHeartbeatと併用することができます。Pacemakerはアクティブ・パッシブ、N+1、N-Nなど、複数のモードを柔軟にサポートしています。各ノードにOCFエージェントをインストールすることで、他のノードがGlanceおよびKeystoneサービスを正しく動作しているか判定し、Pacemakerがこれらのサービスを起動、停止、監視するのを支援します。
5) Swiftオブジェクトストレージの高可用性
一般に、OpenStackの分散オブジェクトストレージシステムであるSwiftは、追加のHA構成を必要としません。これは、Swiftは分散アーキテクチャ（マスターノードなし）を採用しており、耐障害性や冗長化の仕組み、データ回復機能、スケーラビリティ、および高可用性が設計段階で組み込まれているためです。
6) メッセージキュー サービス (RabbitMQ) の高可用性
RabbitMQが障害になると、メッセージが失われる可能性があります。複数のHAメカニズムを使用できます：
パブリッシャーは、障害発生時にもデータがディスクに書き込まれたことを通知するメソッドを確認します。
マルチノードクラスタメカニズムを使用できますが、ノードの障害によりキューの障害が発生する場合があります。
アクティブ・パッシブモードは、障害発生時にフェールオーバーを保証しますが、バックアップノードの起動には遅延や場合によっては失敗が伴うことがあります。
ディザスタリカバリおよび可用性の観点から、RabbitMQはキュー サービスがクラッシュした場合に未処理メッセージをディスク上に保存する永続化キューを提供します。メッセージ送信と書き込みの遅延によるメッセージ損失を防ぐため、RabbitMQはパブリッシャー コンファーム機構を導入し、メッセージが確実にディスクに書き込まれるようにしています。
クラスタのサポートに関して、RabbitMQはアクティブ/パッシブおよびアクティブ/アクティブのモードを提供しています。例えば、アクティブ/パッシブモードでは、ノードが障害になると、パッシブノードが直ちにアクティブ化され、メッセージ配信の処理を継続するために障害が発生したアクティブノードをすばやく置き換えます。
高可用性OpenStackの構築
一般的に、高可用性は冗長性とバックアップを確立することによって実現されます。一般的な戦略には、クラスターモードがあります。これは、複数のマシンが相互にバックアップを行い、中央ノードを持たず、それぞれのインスタンスが複数回バックアップされる方式です。例として、分散オブジェクトストレージシステムであるSwiftやnova-networkのマルチホストモードが挙げられます。
自律モード。 場合によっては、SPoFを各ノードが独立して動作できるようにすることで、マスター・スレーブ関係を排除し、制御ノードの障害による影響を軽減できます。例えば、nova-api は自身のノードのみを担当します。
アクティブ・パッシブモード。この一般的なモデルでは、パッシブノードがスタンバイおよびバックアップ状態を維持し、障害発生時に切り替えが行われます。例として、MySQLの高可用性クラスターや、PacemakerやHeartbeatを通じて冗長性を実現するGlanceやKeystoneなどのサービスがあります。
アクティブ-アクティブモード。 このモードでは、ノードが互いにバックアップおよびサポートを行います。例えば、RabbitMQはアクティブ-アクティブの高可用性クラスターを使用しており、クラスター内のノードがキューを複製できます。アーキテクチャの観点から見ると、この方法により、パッシブノードが起動不能である、または過度な遅延が発生するといった懸念が解消されます。
要約すると、OpenStackの最適化と改善は継続的に進化しており、その導入と応用はさらに探求され、開発されています。実際のチューニングは不可欠です。優れた設計やアイデアは、現実世界でのテストを通じて検証される必要があります。
強化されたOpenStack保護
OpenStackは冗長性と高可用性アーキテクチャを通じてシステムの単一障害点のリスクを低減しますが、データ保護は依然として重要です。事業継続性を確保するためには、データ損失や重大な障害の影響を防ぐために専門のバックアップソリューションを採用する必要があります。
Vinchin Backup & Recovery は、重複排除、圧縮、増分バックアップ、ファイルレベル復旧、クラウドアーカイブなどの機能を備えたエージェントレスで効率的なOpenStackバックアップソリューションです。迅速な復旧、OpenStackとのシームレスな統合、強固なデータセキュリティを実現しており、クラウド環境の管理と保護に最適な選択肢です。
さらに、データ暗号化およびランサムウェア対策は、OpenStack VMのバックアップを保護するための二重の保険を提供します。また、OpenStack ホストから別の仮想プラットフォーム（VMware、Hyper-V、Proxmox、XenServer、oVirt、AWS EC2など）へ簡単にデータを移行したり、逆方向への移行も行うことができます。
OpenStackのVMをVinchin Backup & Recoveryでバックアップするには、以下の4つのステップのみ必要です:
1. バックアップ対象を選択します。
2. バックアップ先を選択します。
3. バックアップ戦略を構成します。
4. 求人票の確認と送信
Vinchin Backup & Recovery は数千社の企業から信頼されています。今すぐ60日間のフル機能トライアルを始めましょう！
OpenStackの高可用性に関するよくある質問
1. OpenStackにおける可用性ゾーンとは何ですか？
OpenStackにおいて、可用性ゾーン（AZ）とは、クラウド環境内で論理的なパーティションを提供し、障害耐性とリソース管理を向上させるためにワークロードを分散するのに役立つ概念です。各AZは独立した障害ドメインであり、異なるAZ内に存在するインスタンスは、同じハードウェアやネットワークの障害の影響を受けにくいことを意味します。AZは通常、コンピュートノードのグループ化に使用されますが、ストレージやネットワーキングサービスもまた独自のゾーンを持つことで、より高い耐障害性と冗長性を実現できます。ユーザーはインスタンス起動時にAZを指定することで、パフォーマンスと信頼性を最適化することが可能です。
2. OpenStackはSAASですか、それともPaaSですか？
OpenStackは主にIaaSプラットフォームです。仮想化されたコンピュート、ストレージ、ネットワーキングリソースを提供し、ユーザーがクラウドインフラを展開および管理できるようにしています。OpenStackはKubernetesやCloud Foundryなどのサービスを上位で動作させることでPaaSソリューションもサポートできますが、そのコア機能はSaaSやPaaSではなくIaaSを提供することにあります。
結論
OpenStackで高可用性を確保するには、アーキテクチャ戦略と技術的解決策を組み合わせて単一障害点を排除し、システムの耐障害性を高める必要があります。アクティブ・パッシブモードやアクティブ・アクティブモードの導入、クラスタリング技術の活用、Nova、Glance、Keystone、RabbitMQなどの主要コンポーネントの最適化により、OpenStackはフォールトトレラントで高信頼性なクラウドインフラを実現できます。さらに、Swiftなどの分散ストレージソリューションは、本来的に冗長性と耐障害性を提供します。
