4年！ OpenStackの運用と保守のアーキテクチャについての私のまとめ

序文

シロクマさんに誘われて、何か書きます。よく考えてみると、クラウドコンピューティングの範囲は本当に広いので、最近非常に話題になっており、大多数のクラウドコンピューティング実践者が深く愛し、苦痛を感じているものについてお話ししましょう。 OpenStack を愛していると伝えたいのですが、それは簡単なことではありません。

ここでは、OpenStack クラウドプラットフォームについて、技術的な観点から、導入、アーキテクチャ、運用保守の実装に関する私の考えを述べたいと思います。

私が初めて OpenStack に触れたのは大学 2 年生の 2014 年のことでした。当時は国内外の情報が今ほど豊富ではありませんでした。 OpenStack H バージョン環境のインストール (VMware Workstation を使用してラップトップ上の 2 つの仮想マシンを仮想化) に 1 週間以上かかりましたが、結局仮想マシンを作成できませんでした。その後、OpenStackを学ぶために、卒業間近の頃に上海へインターンシップに行きました。気がつけば4年が経っていました。

OpenStack には、コンピューティング、ストレージ、ネットワーク、アーキテクチャ、製品、運用と保守、監視とパフォーマンスの最適化、コードなど、さまざまな要素が含まれます。ここで私自身の見解を述べ、過去 4 年間の OpenStack に対する理解についてお話ししたいと思います。それは説明としても捉えられる。間違いがあれば、遠慮なく批判してください。

実際、優れたアーキテクチャ設計と運用および保守保証対策は、OpenStack クラウドプラットフォームの安定した健全な運用に計り知れないほどのプラスの影響を与えることができます。簡単に言えば、実稼働レベルの OpenStack クラウドプラットフォームを展開するには、物理インフラストラクチャ層、ストレージ層、OpenStack クラウドサービス層、ユーザーアプリケーション層という少なくとも 4 つのレベルが関係します。下の図の通りです。

物理インフラストラクチャ層

まず、一番下の「物理インフラストラクチャ層」から始めましょう。基本的な物理インフラストラクチャ IT 環境には、電源設備、空調設備、防火設備、ネットワーク設備 (スイッチ、ルーター、ファイアウォール、負荷分散設備など)、ストレージデバイス、サーバーが含まれます。専門知識の制限により、ここではスイッチとサーバーのみが関係します。基本的な物理 IT 環境を下図に示します。

スイッチ機器

通常、OpenStack の実稼働環境では、スイッチポートを集約 (チャネル) する必要があります。つまり、2 つ以上の物理ポートを論理リンクに結合してスイッチとネットワークノード間の帯域幅を増やし、これらのポートに属する帯域幅をマージして、独立したポートの数倍の専用の高帯域幅をポートに提供します。トランクはカプセル化技術です。ポイントツーポイントリンクです。リンクの両端は、スイッチ、スイッチとルータ、またはホストとスイッチまたはルータにすることができます。

サーバ

ネットワークカード

OpenStack クラウドプラットフォームに関係するネットワークには、管理ネットワーク (OpenStack サービス間の通信に使用)、外部ネットワーク (フローティング IP を提供)、ストレージネットワーク (Ceph ストレージネットワークなど)、仮想マシンネットワーク (テナントネットワーク、ビジネスネットワークとも呼ばれます) などがあります。

各タイプのネットワークごとに、サーバーにはネットワークカードボンドが備わっており、サーバーネットワークに冗長性、高可用性、負荷分散機能を提供する必要があります。実際のニーズに応じて、モード 0 またはモード 1 を選択できます。ネットワークトラフィックが重いシナリオではボンド 0 が推奨され、信頼性の要件が高いシナリオではボンド 1 が推奨されます。

両者の長所と短所を比較してください。

一般的に、小規模なプライベートクラウド環境では、ネットワークタイプに対応する帯域幅は次のようになります。

管理ネットワーク: ギガビットネットワーク
外部ネットワーク: ギガビットネットワーク
ストレージネットワーク: 10ギガビットネットワーク
テナントネットワーク: ギガビットネットワーク

中規模から大規模のプライベートクラウドやパブリッククラウド環境の場合は、可能な限り10ギガビットネットワークを使用することをお勧めします。

ハードディスク

サーバーオペレーティングシステムで使用されるシステムディスクは、システムストレージの信頼性を高めるために、2 つのハードディスクを使用して RAID 1 を形成する必要があります。オペレーティングシステム、MySQL データベース、Docker コンテナー (OpenStack の展開に Kolla を使用する場合) の IO ストレージパフォーマンスを向上させるには、高性能でコスト管理された SAS ハードディスクを使用することをお勧めします。

CPU

仮想マシンの移行機能が正常かつ利用可能であることを保証するには、各 OpenStack コンピューティングノードの CPU モデルが一貫している必要があります。

メモリ

仮想マシンの作成と管理のバランスの取れたスケジュールを確保するには、各 OpenStack コンピューティングノードのメモリサイズが一貫している必要があります。同時に、ホストのスワップパーティションは科学的かつ合理的に設定する必要があり、システムのデフォルトで作成されたものは使用できません。

データセンター内の少数のマシンは制御ノードとして使用され、ほとんどのマシンでは仮想化ソフトウェアを実行する必要があります。仮想化プラットフォーム上には多数の VM があり、ホストシステム自体もいくつかのサービスを実行します。これにより、必然的に VM 間および VM とホストシステム間でリソースのプリエンプションが発生します。それぞれの境界内で効率的に実行し、競合や先取権を減らすためのルールを設定する必要があります。

オペレーティングシステムの実行時にホストマシンがさらに指定されたコアを選択できるようにすることで、仮想化における仮想マシンの vCPU スケジューリングが過剰に優先されることがなくなります。カーネルの起動パラメータを変更することで、次のことが可能になります。

システムが最初の 3 つのコアのみを使用し、残りのコアを分離するように、/etc/default/grub ファイルを変更します。

 GRUB_CMDLINE_LINUX_DEFAULT= "isolcpus=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31"

カーネルパラメータを更新する

#アップデート-grub  
 # 再起動

メモリ構成に関しては、NetEase Private Cloud では KVM メモリ共有をオフにし、透過的な巨大ページをオンにすることを実践しています。

エコー 0 > /sys/kernel/mm/ksm/pages_shared  
エコー 0 > /sys/kernel/mm/ksm/pages_sharing  
常にエコー > /sys/kernel/mm/transparent_hugepage/enabled  
エコーなし > /sys/kernel/mm/transparent_hugepage/defrag  
エコー 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

SPEC CPU2006 テストでは、これらの構成によりクラウドホストの CPU パフォーマンスが約 7% 向上すると言われています。

OpenStack クラウドプラットフォームレイヤー

クラウドプラットフォームの高可用性 (HA)

高可用性 (HA) の概要

高可用性とは、障害がビジネスプロセス、物理的な設備、IT ソフトウェアまたはハードウェアの障害であるかどうかに関係なく、ローカルシステム内の単一のコンポーネントに障害が発生した場合でも、アプリケーションへの継続的なアクセスを提供する能力を指します。最高の可用性とは、マシンの 1 つがダウンしても、サービスのユーザーがまったく気付かないことです。マシンがダウンした場合、そのマシン上で実行されているサービスはフェイルオーバーする必要があります。フェイルオーバーには、RTO (目標復旧時間) と RPO (目標復旧ポイント) という 2 つのコストの側面があります。 RTO は、サービスを復旧するのにかかる時間です。最良のケースは 0 であり、これはサービスが直ちに復旧することを意味します。最悪のケースは無限であり、サービスが回復できないことを意味します。 RPO は、切り替え中にデータを復元するのにかかる時間の長さです。 0 は同期されたデータを使用することを意味し、0 より大きい場合はデータが失われることを意味します。たとえば、「RPO = 1 日」は、リカバリ時に 1 日前のデータが使用されるため、1 日以内のデータが失われることを意味します。したがって、回復のための最良の結果は RTO = RPO = 0 ですが、これは実現するには理想的すぎるか、コストがかかりすぎます。

HA の場合、分散ストレージが使用されることが多く、その場合 RPO = 0 になります。同時に、アクティブ/アクティブ（アクティブ-アクティブクラスター）HA モードを使用して、RTO をほぼ 0 にします。アクティブ/パッシブ HA モードを使用する場合は、RTO を最小限に抑える必要があります。 HAの計算式は[1 - (ダウンタイム)/(ダウンタイム + アップタイム)]です。可用性を表すために、複数の 9 がよく使用されます。

2 9: 99% = 1% 365 = 3.65 24 時間/年 = 87.6 時間/年のダウンタイム
4 9s: 99.99% = 0.01% 365 24 * 60 = 52.56 分/年
ファイブナイン: 99.999% = 0.001% * 365 = 年間 5.265 分のダウンタイム、つまり各ダウンタイムは 1 ～ 2 分であることを意味します。
11 ナイン: 数分間のダウンタイムが数年間続く。

サービスの分類

HA はサービスを 2 つのカテゴリに分類します。

ステートフルサービス: サービスへの後続のリクエストは、サービスへの以前のリクエストに依存します。 OpenStack のステートフルサービスには、MySQL データベースと AMQP メッセージキューが含まれます。 neutron-l3-agent、neutron-metadata-agent、nova-compute、cinder-volume などのステートフルサービスの HA の場合、最も簡単な方法は、それらを複数のノードにデプロイすることです。たとえば、特定のノード上の nova-compute サービスがクラッシュしても、クラウドプラットフォーム全体に影響はなく、仮想マシンを作成できなくなったり、ノード上の仮想マシンが使用できなくなったりすることはありません (ssh など)。
ステートレスサービス: サービス要求間に依存関係はなく、完全に独立しており、冗長インスタンスと負荷分散に基づいて HA が実現されます。 OpenStack のステートレスサービスには、nova-api、nova-conductor、glance-api、keystone-api、neutron-api、nova-scheduler などがあります。API サービスはステートレスサービスであるため、当然、アクティブ/アクティブ HA モードをサポートします。したがって、keepalived + HAProxy ソリューションが一般的に使用されます。

HAの種類

HA では、アプリケーションやサービスなどのワークロードを実行するために、冗長サーバーを使用してクラスターを形成する必要があります。この冗長性は、HA の 2 つのカテゴリに分けられます。

アクティブ/パッシブ HA: アクティブ/パッシブ HA。この構成では、システムはプライマリマシンとバックアップマシンを使用してサービスを提供し、プライマリデバイスでのみサービスを提供します。プライマリデバイスに障害が発生すると、プライマリデバイスによって提供されるサービスを置き換えるために、バックアップデバイス上のサービスが開始されます。通常、Pacemaker などの CRM ソフトウェアを使用して、プライマリデバイスとバックアップデバイス間の切り替えを制御し、サービスを提供するために仮想 IP を提供できます。
アクティブ/アクティブ HA: 複数のノードが含まれる場合、マルチマスターと呼ばれるアクティブ/アクティブ HA。この構成では、システムはクラスター内のすべてのサーバーで同じワークロードを実行します。データベースを例にとると、1 つのインスタンスに対する更新はすべてのインスタンスに同期されます。この構成では、サービスの仮想 IP を提供するために、HAProxy などの負荷分散ソフトウェアがよく使用されます。

OpenStack クラウド環境の高可用性 (HA)

クラウド環境は、インフラストラクチャ層、OpenStack クラウドプラットフォームサービス層、仮想マシン、エンドユーザーアプリケーション層を含む広範なシステムです。

クラウド環境の HA には以下が含まれます。

ユーザーアプリケーションのHA
仮想マシンのHA
OpenStack クラウドプラットフォームサービスの HA
インフラストラクチャ層の HA: 電源、空調、防火設備、ネットワーク機器 (スイッチ、ルーターなど)、サーバー機器、ストレージ機器など。

OpenStack クラウドプラットフォームサービス (nova-api、nova-scheduler、nova-compute など) を例にとると、その数は数十から数百に上ります。サービスに障害が発生した場合、対応する機能は正常に使用できなくなります。そのため、クラウド環境全体の HA 高可用性をどのように確保するかが、アーキテクチャ設計と運用保守の最重要課題となっています。

OpenStack HA 高可用性アーキテクチャを次の図に示します。

デプロイメントレベルから分けると、OpenStack の高可用性には次のものが含まれます。

制御ノード (Rabbitmq、mariadb、Keystone、nova-api など)
ネットワークノード (neutron_dhcp_agent、neutron_l3_agent、neutron_openvswitch_agent など)
コンピューティングノード (Nova-Compute、neutron_openvswitch_agent、仮想マシンなど)
ストレージノード (cinder-volume、swift など)

制御ノード HA

実稼働環境では、少なくとも 3 つの制御ノードを展開することをお勧めします。残りは、コンピューティングノード、ネットワークノード、またはストレージノードとして使用できます。 Haproxy + KeepAlived を使用してデータベースサービスと OpenStack サービスをプロキシし、VIP を公開して API アクセスを提供します。

MySQL データベース HA

MySQL には多くの HA ソリューションがあります。ここでは、Openstack によって公式に推奨されている MariaDB Galara クラスターについてのみ説明します。 Galera Cluster は、InnoDB ストレージエンジン上でマルチマスターとリアルタイムのデータ同期を実装するシステムアーキテクチャです。ビジネスレベルでの読み取りと書き込みの分離を実行する必要がなく、確立されたルールに従ってデータベースの読み取りと書き込みの負荷を各ノードに分散できます。特徴は次のとおりです。

同期レプリケーション、(>=3) 奇数ノード
アクティブ-アクティブマルチマスタートポロジ
クラスタ内のどのノードでも読み取りと書き込みが可能
自動アイデンティティ制御、障害が発生したノードは自動的にクラスターから離脱します
自動ノードアクセス
「行」レベルとIDチェックに基づく真の並列レプリケーション
単一障害点がなく、拡張が容易

MariaDB + Galera ソリューションを使用して、少なくとも 3 つのノード (できれば奇数ノード) をデプロイし、外部アクセスは Haproxy のアクティブ + バックエンドメソッドを通じてプロキシされます。通常、メインデータベースは A です。A に障害が発生すると、ノード B または C に切り替わります。下の図を参照してください。

RabbitMQ メッセージキュー HA

RabbitMQ はネイティブの Cluster ソリューションを使用し、すべてのノードがミラーキューを同期します。小規模環境では、物理マシンが 3 台あり、そのうち 2 つの Mem ノードが主にサービスを提供し、1 つの Disk ノードがメッセージを永続化するために使用されます。クライアントは、ニーズに応じてマスタースレーブ戦略を構成します。デフォルトの RabbitMQ の代わりに ZeroMQ を使用すると、クラスターメッセージキューのパフォーマンスが向上すると言われています。

OpenStack API サービス HA

OpenStack 制御ノードは基本的に、nova-api、neutron-server、glance-registry、nova-novncproxy、keystone などの API ステートレスサービスを実行します。そのため、HAProxy は負荷分散を提供し、特定のアルゴリズムに従って特定のノード上の API サービスにリクエストを転送し、KeepAlived は VIP を提供できます。

ネットワークノード HA

ネットワークノードで実行される Neutron サービスには、L3 エージェント、openvswitch エージェント、LBaas、VPNaas、FWaas、メタデータエージェントなど、多くのコンポーネントが含まれます。これらのコンポーネントの一部は、ネイティブ HA サポートを提供します。

OpenvswitchエージェントHA: openvswitchエージェントは、それが配置されているネットワークまたはコンピューティングノード上でのみサービスを提供するため、HAは必要ありません。
L3エージェントHA: VRRPとDVRは2つの成熟した主流のソリューションです
DHCPエージェントHA: HAを実現するために複数のネットワークノードにDHCPエージェントを展開する
LBaas Agent HA: A/P LBaas Agent HA を展開するための Pacemaker + 共有ストレージ (/var/lib/neutron/lbaas/ ディレクトリに配置)

ストレージノード HA

ストレージノードの HA は、主に cinder-volume および cinder-backup サービスを対象としています。最も簡単な方法は、複数のストレージノードを展開することです。特定のノード上のサービスに障害が発生しても、システム全体に影響は及びません。

コンピューティングノードと仮想マシンの HA

コンピューティングノードと仮想マシン HA。コミュニティは 2016 年 9 月から仮想マシン HA の統合ソリューションに取り組んでいますが、まだ成熟したソリューションは存在しません。コンピューティングノードと仮想マシンの HA を実現するには、基本的に次の 3 つのことを行う必要があります。

① モニタリング

監視は主に 2 つのことを行います。 1 つは、コンピューティングノードのハードウェアおよびソフトウェアの障害を監視することです。 2 つ目は、障害の原因となる処理イベント、つまり分離と回復です。

OpenStack コンピューティングノードは、pacemaker と pacemaker_remote を使用して高可用性を実現できます。 pacemaker_remote を使用した後、すべてのコンピューティングノードをこのクラスターに追加できます。コンピューティングノードには pacemaker_remote のみをインストールする必要があります。 pacemaker クラスターは、コンピューティングノード上の pacemaker_remote が「アクティブ」であるかどうかを監視し、何が「アクティブ」であるかを定義できます。たとえば、コンピューティングノード上の nova-compute、neutron-ovs-agent、libvirt などのプロセスを監視して、コンピューティングノードが稼働しているかどうか、またはテナントネットワークやその他のネットワークが切断されているかどうかを判断できます。 pacemaker_remote に問題があることが監視されている場合、後続の分離イベントと回復イベントを直ちにトリガーできます。

② 隔離

分離の主なタスクは、正常に動作していないコンピューティングノードを OpenStack クラスター環境から削除し、nova-scheduler が create_instance メッセージをコンピューティングノードに送信しないようにすることです。

Pacemaker には fence 機能が統合されているため、 fence_ipmilan を使用してコンピューティングノードをシャットダウンできます。 Pacemaker クラスターでは、コンピューティングノードがダウンした場合にのみ nova が host-evacuate を実行して仮想マシンを移行できるため、fence_compute は常にコンピューティングノードがダウンしているかどうかを監視します。また、待機時間が少し長くなります。より良い方法は、nova service-force-down コマンドを呼び出して、コンピューティングノードを直接ダウンとしてマークすることです。これにより、仮想マシンの移行が高速化されます。

③ 回復

リカバリとは、ダウン状態にあるコンピューティングノード上の仮想マシンを他のコンピューティングノードに移行することです。 Pacemaker クラスターは、ホスト避難 API を呼び出してすべての仮想マシンを移行します。最後に、host-evacuate は再構築を使用して仮想マシンを移行します。各仮想マシンは、スケジューラを通じて異なるコンピューティングノード上で起動されます。

もちろん、Consul などの分散ヘルスチェックサービスも使用できます。

仮想マシンのオペレーティングシステムの障害回復

OpenStack の libvirt/KVM ドライバーは、すでにこの種の問題を非常にうまく自動的に処理できます。具体的には、フレーバーの extra_specs またはイメージのプロパティに hw:watchdog_action を追加すると、VM にウォッチドッグデバイスが設定されます。 hw:watchdog_action が reset に設定されている場合、仮想マシンのオペレーティングシステムがクラッシュすると、watchdog は自動的に仮想マシンを再起動します。

OpenStack コンピューティングリソースの制限

メモリの設定

デフォルトのメモリ割り当て過剰率は 1.5 倍です。実稼働環境では過剰販売を有効にすることは推奨されません。

 ram_allocation_ratio = 1

メモリ予約。このメモリ部分は、システムの正常な動作を保証するために仮想マシンで使用できません。

 reserved_host_memory_mb = 10240 // たとえば、10 GBが予約されています

CPUの設定

nova を通じて仮想化リソースの使用を制御できます。 OpenStack はいくつかの構成を提供し、nova.conf ファイルを変更します。仮想マシン vCPU のバインド範囲により、仮想マシンがホストプロセスの CPU リソースを競合するのを防ぐことができます。推奨値は、最初のいくつかの物理 CPU を予約することです。

 vcpu_pin_set = 4-31

物理CPUの過剰販売率、デフォルトは16倍、ハイパースレッディングも1つの物理CPUとしてカウントされます

CPU割り当て比率 = 8

複数のリージョンとAZの使用

OpenStack クラウドプラットフォームを複数のデータセンターまたはリージョンにまたがって展開する必要がある場合は、マルチリージョンおよびアベイラビリティゾーン (AZ) ソリューションを使用できます。このように、各コンピュータルームは地理的に自然に分離され、上位レベルのアプリケーションにとって自然な災害復旧方法となります。

マルチリージョン展開

OpenStack は、地理的な場所に基づいて異なるリージョンに分割することをサポートします。 Keystone および Horizon サービスの共有に加えて、各リージョンは完全な OpenStack 環境です。全体として、複数のリージョン間の展開は比較的独立していますが、イントラネット専用回線 (BGP-EVPN など) を介して相互接続できます。そのアーキテクチャを下の図に示します。

デプロイするときは、共通の Keystone および Horizon サービスのセットをデプロイするだけで済みます。その他のサービスは単一リージョンモードでデプロイでき、リージョンはエンドポイントを通じて指定できます。ユーザーは、リソースを要求するときに特定のリージョンを指定する必要があります。このアプローチにより、さまざまな領域に分散されたリソースの管理を統一でき、領域ごとに異なるデプロイメントアーキテクチャや異なるバージョンを採用できるようになります。その利点は次のとおりです。

展開は簡単で、リージョン展開ごとに追加の構成はほとんど必要なく、リージョンを簡単にスケールアウトできます。
障害領域は分離されており、各領域は互いに影響を及ぼしません。
柔軟かつ自由であり、さまざまな領域でさまざまなアーキテクチャ、ストレージ、ネットワークを使用できます。

ただし、このソリューションには明らかな欠点もあります。

各エリアは完全に分離されており、相互にリソースを共有することはできません。たとえば、リージョン A で作成されたボリュームは、リージョン B の仮想マシンにマウントできません。リージョン A のリソースをリージョン B に割り当てることができないため、リージョン負荷の不均衡という問題が発生する可能性があります。
各リージョンは完全に独立しており、リージョン間の移行はサポートされていません。リージョンクラスタに障害が発生した場合、仮想マシンを別のリージョンクラスタに退避することはできません。
Keystone が主なパフォーマンスのボトルネックになっています。 Keystone の可用性は保証されなければなりません。そうしないと、すべての地域のサービスに影響が出ます。この問題は、複数の Keystone ノードを展開することで解決できます。

OpenStack マルチリージョンソリューションは、大規模なクラスターを複数の小さなクラスターに分割し、それらを統一的に管理することで、大規模な物理リソースの統合管理を実現します。これは、複数のデータセンターにまたがり、さまざまな地域に分散されているシナリオに特に適しています。この場合、北京や上海など、地域の場所に応じてリージョンが分割されます。ユーザーにとっても、次のようなメリットがあります。

ユーザーは自分の位置に基づいて最も近いエリアを選択できるため、ネットワークの遅延が短縮され、アクセスが高速化されます。
ユーザーは、さまざまなリージョンで災害復旧を実装することを選択できます。ある地域で大きな障害が発生した場合、ビジネスを別の地域に迅速に移行できます。

マルチアベイラビリティゾーンの展開

コンピュータールームに OpenStack クラウド環境を展開したいだけの場合。 AZ ソリューションのみを使用する必要があります。各 AZ には、独立した電源を備えた独自のラックと OpenStack コンピューティングノードがあります。

可用性ゾーン

リージョンは、物理的または論理的に分離された 1 つ以上の可用性ゾーン (AZ) に分割できます。仮想マシンを起動するときに、特定の AZ または特定の AZ 内のノードを指定して仮想マシンを起動できます。 AZ は、独立した電源装置を備えたノードの集合として簡単に理解できます。たとえば、独立電源が供給される各コンピュータルームまたは独立電源が供給される各ラックを AZ に分割できます。

次に、リージョン内の複数の AZ にアプリケーションの複数の仮想マシンをデプロイして、仮想マシンの耐障害性と可用性を向上させます。 AZ は物理的に分離されているため、1 つの AZ に障害が発生しても他の AZ には影響しません。同時に、リモートアクティブ/アクティブと同様に、ダウンした AZ 上の仮想マシンを他の通常利用可能な AZ に移行することもできます。

ホストアグリゲート

AZ に加えて、コンピューティングノードはホストアグリゲート (ホストアグリゲート、略して HA) に論理的に分割することもできます。ホスト集約では、メタデータを使用してコンピューティングノードのグループにラベルを付けます。コンピューティングノードは、競合することなくホストアグリゲートと AZ に同時に属することができ、複数のホストアグリゲートに属することもできます。

ホストによって集約されたノードには共通のプロパティがあります。たとえば、CPU は特定のタイプのノードのグループ、ディスクは SSD ノードのグループ、OS は Linux または Windows ノードのグループなどです。ホストアグリゲートはユーザーには見えない概念であることに注意してください。これは主に、nova-scheduler の特定の属性を通じてインスタンスをスケジュールするために使用されます。たとえば、データベースサービスのすべてのインスタンスを SSD 属性を持つホストアグリゲートにスケジュールしたり、特定のフレーバーまたはイメージのインスタンスを同じホストアグリゲートにスケジュールしたりできます。

簡単に言えば、リージョン、アベイラビリティーゾーン、ホストアグリゲートは、大きいものから小さいものへと関連しており、つまり、前者は後者を包含します。地理的リージョンには複数の可用性ゾーン (AZ) が含まれます。同じ AZ 内のコンピューティングノードは、特定のルールに従って論理的にグループに結合できます。たとえば、災害復旧を目的として、北京にリージョンがあり、成都にも別のリージョンがあります。同時に、北京リージョンには 2 つの AZ アベイラビリティゾーン (九仙橋コンピュータールーム、石景山コンピュータールームなど) があります。各 AZ には、独自の独立したネットワークと電源設備、OpenStack コンピューティングノードなどが備わっています。ユーザーが北京にいる場合、VM を展開するときに北京を選択できるため、ユーザーのアクセス速度が向上し、SLA (サービスレベル契約) が向上します。

適切なネットワークソリューションを選択する

ユーザーは、VLAN、VXLAN、GRE などのどのネットワークソリューションを使用するかについて混乱することがよくあります。 VLAN と VXLAN の違いは、VLAN は仮想ルーティング変換を必要としない大規模なレイヤー 2 ネットワークテクノロジである点です。 VXLAN や GRE よりもパフォーマンスが優れており、4094 のネットワークをサポートし、アーキテクチャと運用保守がシンプルです。 VXLAN は、レイヤー 2 データフレームをレイヤー 3 UDP データパケットにカプセル化して送信するオーバーレイネットワークトンネルテクノロジーです。ルーティング変換、パケットのカプセル化、およびアンパックが必要です。パフォーマンスは VLAN よりも劣り、アーキテクチャはより複雑です。ただし、1,600 万を超えるネットワークをサポートしており、優れたスケーラビリティを備えています。

企業ユーザーのクラウドプラットフォームが長期間にわたって小規模 (たとえば、仮想マシンが 10,000 台未満) であり、マルチテナントネットワークのセキュリティ分離に対する要件が高くない場合は、VLAN ネットワークを使用できます。一方、ネットワークセキュリティの分離が極めて重要である場合や、クラウドプラットフォームが非常に大きい場合は、VXLAN ネットワークソリューションを使用できます。

VXLAN および VLAN ネットワーク通信、つまりテナントプライベートネットワークと Floating IP 外部ネットワークのルーティングおよび転送通信のコンテキストでは、OpenStack の従来の集中型ルーティング環境では、南北トラフィックとネットワーク間の東西トラフィックはデフォルトでネットワークノードを通過する必要があります。コンピューティングノードの規模が大きくなると、ネットワークノードがすぐにシステム全体のボトルネックになります。この問題を解決するために、分散仮想ルーター (DVR) の概念が導入されました。 DVR ソリューションを使用すると、ルートをコンピューティングノードに配布できます。ネットワークセグメント全体の南北トラフィックと東西トラフィックは、仮想マシンが配置されているコンピューティングノード上の仮想ルーターによってルーティングされるため、安定性とパフォーマンスが向上します。

クラウドプラットフォームのデータをバックアップする

諺にあるように、バックアップがあれば、安心して眠れます。実際の環境では、さまざまな理由によりデータが削除される可能性があります。たとえば、クラウドプラットフォーム内のデータベース、仮想マシン、データボリューム、イメージ、または基盤となるストレージが削除された場合、データがバックアップされていないと悲惨な結果になります。

OpenStack+Ceph アーキテクチャで構成されるクラウドプラットフォーム環境には、N 個のデータバックアップソリューションがあります。たとえば、OpenStack には独自の Karbor および Freezer クラウドサービスがあり、Ceph にも関連するバックアップソリューションがあり、その他の商用バックアップソリューションもあります。実際、OpenStack クラウドプラットフォーム自体も、仮想マシンのスナップショット/バックアップやデータボリュームのスナップショット/バックアップなど、優れた使いやすいバックアップ機能を提供しています。使用時には、データボリュームを仮想マシンにマウントして、データをクラウドディスクに書き込み、間接的にデータ災害復旧バックアップを実現することも推奨されます。

何らかの理由で、物理データセンターまたはリージョン全体にリージョンと AZ が存在しない場合。そのため、OpenStack クラウドプラットフォームに関連するデータのバックアップは必須です。たとえば、MySQL データベースは、実際のニーズに応じて数時間ごとにバックアップできます。バックアップデータを他のマシンに保存することをお勧めします。 Ceph の基盤となるストレージバックアップソリューションとしては、RBD ミラーリングソリューションを使用できます。

RBD ミラーリングは、Ceph の新しい非同期バックアップ機能です。 2 つの Ceph クラスター間の rbd 同期の構成をサポートします。このソリューションでは、マスタークラスターは高性能ストレージデバイスを使用して、OpenStack の Glance、Cinder (cinder-volume、cinder-backup)、および Nova サービスに提供します。一方、バックアップクラスターは、大容量で低コストのストレージデバイス (SATA ディスクなど) を使用して Ceph データをバックアップします。さまざまな Ceph Cluster クラスターでは、実際のニーズに基づいて、物理的なコンピュータールーム間でバックアップするかどうかを選択できます。下の図の通りです。

アドバンテージ：

新しい Ceph 機能、追加開発は不要
同期の粒度は比較的小さく、ブロックデバイスのトランザクションです。
クラッシュの一貫性を保証
プールのバックアップを構成することも、イメージのバックアップを個別に指定することもできます。
同期バックアップ、異なるコンピュータルームの Ceph クラスター、および基盤となるストレージのコンピュータルーム間の災害復旧

適切なDockerストレージを使用する

OpenStack クラウドプラットフォームは、Kolla コンテナ化を使用してデプロイおよび管理されます。したがって、正しく適切な Docker ストレージを選択することは、プラットフォームの安定性とパフォーマンスに関係します。

Docker はストレージドライバーを使用して、イメージの各レイヤーと読み取りおよび書き込み可能なコンテナーレイヤーのコンテンツを管理します。ストレージドライバーには、devicemapper、aufs、overlay、overlay2、btrfs、zfs などがあります。ストレージドライバーによって実装方法が異なり、イメージの編成形式も若干異なる場合がありますが、いずれもスタックストレージを使用し、Copy-on-Write (CoW) 戦略を採用しています。ストレージドライブはホットスワップ可能なアーキテクチャを採用しており、動的に調整できます。では、ストレージドライバーが多数ある場合、適切なものをどのように選択すればよいのでしょうか?次の点を考慮することができます。

カーネルが複数のストレージドライバーをサポートしていて、明示的な構成が指定されていない場合、Docker は内部の優先順位設定に基づいて 1 つを選択します。優先順位は、aufs > btrfs/zfs > overlay2 > overlay > devicemapper です。 devicemapper を使用する場合は、実稼働環境で direct-lvm を選択する必要があります。 Loopback-lvm のパフォーマンスは非常に低いです。
選択は、Docker のバージョン、オペレーティングシステム、システムのバージョンなどによって制限されます。たとえば、aufs は Ubuntu または Debian システムでのみ使用でき、btrfs は SLES (SUSE Linux Enterprise Server、Docker EE でのみサポート) でのみ使用できます。
一部のストレージドライバーはバックエンドファイルシステムに依存します。たとえば、btrfs は btrfs と呼ばれるバックエンドファイルシステム上でのみ実行できます。
ストレージドライバーによって、アプリケーションシナリオに応じたパフォーマンスが異なります。たとえば、aufs、overlay、overlay2 はファイルレベルで動作し、メモリの使用が比較的効率的になります。ただし、大きなファイルを読み書きする場合、コンテナ層は非常に大きくなります。 Devicemapper、btrfs、zfs はブロックレベルで動作し、書き込み負荷が高いシナリオでの作業に適しています。コンテナレイヤーが多く、小さなファイルが頻繁に書き込まれる場合は、overlay よりも overlay2 の方が効率的です。 btrfs と zfs はより多くのメモリを消費します。

Docker コンテナは実際にはイメージの上に読み取り/書き込みレイヤーを追加します。これは一般にコンテナレイヤーとも呼ばれます。新しいファイルの書き込み、既存のファイルの変更、ファイルの削除など、実行中のコンテナで作成されたすべての変更は、実際にコンテナレイヤーに書き込まれます。ストレージドライバーは、ファイルシステムに画像とコンテナが保存および整理される方法を決定します。生産環境では、Centos 7.4システムとその4.15カーネルバージョン + Dockerバージョン1.13.1を使用しています。したがって、Overlay2ストレージが使用されます。以下は、Overlay2の簡単な紹介です。

オーバーレイの紹介

OverlayFSは、AUFSと同様のユニオンファイルシステムですが、実装がより単純でパフォーマンスが向上しています。厳密に言えば、OverlayFSはLinuxカーネルのファイルシステムです。対応するDockerストレージドライバーは、オーバーレイまたはオーバーレイ2です。 Overlay2にはLinuxカーネル4.0以上が必要であり、オーバーレイにはカーネル3.18以上が必要です。現在、Docker Community Editionのみがサポートしています。条件が許可されている場合は、オーバーレイよりも高いイノード利用率を持つOverlay2を使用してみてください。

AUFSの複数のレイヤーとは異なり、オーバーレイには2つのレイヤーしかありません。それぞれ、上部ファイルシステムと下部ファイルシステムで、それぞれDockerコンテナレイヤーと画像層を表します。ファイルを変更する必要がある場合、COWを使用して、読み取り専用の下層からファイルを書き込み可能な上層層にコピーして修正のために、結果も上層に保存されます。 Dockerでは、下の読み取り専用レイヤーが画像であり、書き込み可能なレイヤーがコンテナです。構造は、次の図に示されています。

分析します

カーネル3.18から主流のLinuxカーネルに入りました。 AUFSやデバイスマッパーよりも速いシンプルなデザインと高速。場合によっては、BTRFよりも高速です。 Dockerストレージオプションの未来です。 OverlayFSには複数のレイヤーではなく2つのレイヤーしかないため、OverlayFS「コピーアップ」操作はAUFSよりも高速です。これにより、操作の遅延を減らすことができます。

OverlayFSは、ページのキャッシュ共有をサポートしています。同じファイルにアクセスする複数のコンテナは、ページキャッシュを共有できるため、メモリの利用が改善されます。

オーバーレイフはイノードを消費します。画像と容器の数が増えると、巻がボトルネックに遭遇します。 Overlay2はこの問題を解決できます。オーバーレイの下でイノード問題を解決するには、別のファイルシステムにマウント/var/lib/dockerを検討するか、システムのイノード設定を増やすことができます。

分散ストレージを使用します

OpenStack Cloud PlatformがCeph、Glusterfsなどのオープンソース分散ストレージシステムを使用している場合。ストレージシステムの冗長性、災害耐性、信頼性、セキュリティ、パフォーマンスを確保する方法は特に重要です。ここでは、Ceph Open Source分散ストレージを例として取ります。

MonノードとOSDノードの展開

一般に、生産環境では、少なくとも3つのCeph Monノード（できれば奇数）と複数のOSDノードを展開する必要があります。

CEPHX認証を有効にします

同時に、CEPHX認証がデータストレージのセキュリティを改善し、攻撃を防止できるようにします。以下に示すように。

 ＃cat /etc/ceph/ceph.conf  
 [グローバル]  
 FSID = E10D7336-23E8-4DAC-A07A-D012D9208AE1  
 mon_initial_members = computer1、computer2、computer3  
 Mon_host = 172.17.51.54,172.17.51.55,172.17.51.56  
 auth_cluster_required = cephx  
 auth_service_required = cephx  
 auth_client_required = cephx  
 ………

ネットワーク構成

CEPHストレージノードが小さい場合、CEPHパブリックネットワーク（つまり、パブリックネットワーク）はギガビットネットワークを使用でき、クラスターネットワーク（つまり、クラスターネットワーク）は10ギガビットネットワークを使用できます。 CEPHノードが大きく、ビジネス負荷が高い場合は、10Gネットワークを使用してみてください。重要な環境では、CEPHパブリックネットワークとクラスターネットワークを分離する必要があります。ネットワークカードの故障によるネットワーク中断を防ぐために、CEPHストレージノードで使用されるネットワークカードを接着する必要があることに注意してください。

キャッシュティアを使用します

クラウドストレージ環境では、コストの考慮事項のために、SSDハードドライブは一般に少量で使用され、SATAハードドライブは大量に使用されます。 OpenStackがCephと統合されているクラウド環境でSSDとSATAハードディスクの使用方法。通常、それを使用する2つの方法があります。

最初の方法：それぞれ独立したSSDおよびSATAストレージリソースクラスターを作成します。次に、Cinderブロックストレージサービスは、SSDメディアとSATAメディアでクラウドハードディスクを同時に作成および使用できるように、Ceph Backendストレージの2つのセットに接続します。
2番目の方法は、SSDハードディスクを使用して、比較的小さいが高いパフォーマンスを持つキャッシュプール（キャッシュティア）を作成し、SATAハードディスクを作成して、大容量が低いがパフォーマンスが低いストレージプール（ストレージ層）を作成することです。

ここでは、2番目の方法を例として取ります。クライアントが操作データにアクセスすると、キャッシュティアデータの読み書きが優先されます（もちろん、キャッシュモードに依存します）。データがストレージ層にある場合、キャッシュ層に宣伝されます。キャッシュ層では、リクエストヒットアルゴリズム、キャッシュフラッシングアルゴリズム、キャッシュエリミネーションアルゴリズムなどがあり、これにより、ホットデータがキャッシュ層に促進され、コールドデータがストレージ層に移動します。

キャッシュレイヤープロキシは、キャッシュレイヤーとバックエンドストレージの間のデータ移行を自動的に処理します。使用中、ニーズに応じて移行ルールを構成できます。主なシナリオは2つあります。

書き込みバックモード：管理者がキャッシュレイヤーを書き込みバックモードに設定すると、CEPHクライアントはキャッシュレイヤーにデータを書き込み、キャッシュレイヤーからACKを受信します。キャッシュ層に書き込まれたデータは、ストレージ層に移行され、キャッシュ層から洗い流されます。直感的に、キャッシュ層はバックエンドストレージ層の前にあります。 CEPHクライアントが読みたいデータがストレージレイヤーにある場合、キャッシュレイヤーエージェントはデータをキャッシュレイヤーに移行し、CEPHクライアントに送信します。この時点から、CEPHクライアントは、データが読み取られたり書かれなくなるまで、キャッシュレイヤーでI/O操作を実行します。このモードは、揮発性データ（写真/ビデオ編集、トランザクションデータなど）に最適です。

読み取り専用モード：管理者がキャッシュレイヤーをReadonlyモードに設定すると、Cephはデータをバックエンドに直接書き込みます。読むとき、Cephはバックエンドからキャッシュレイヤーに対応するオブジェクトをコピーします。定義されたポリシーによると、汚れたオブジェクトはキャッシュレイヤーから追い出されます。このモードは、キャッシュレイヤーから読み取られるデータに期限切れのデータが含まれている可能性があるため、一貫性が低いため、不変のデータ（ソーシャルネットワーク、DNAデータ、X線写真などに表示される写真/ビデオなど）に適しています。揮発性データにReadonlyモードを使用しないでください。

プールを独立して使用します

Cephは、OpenStack Cinderブロックストレージサービス（Cinder-Volume、Cinder-Backup）、Nova Compute Services、およびGlance Image Servicesのバックエンドストレージを統合できます。生産環境では、OpenStackの4つのサービスストレージに対応する4つのストレージリソースプールを作成することをお勧めします。同時に、次の表に示すように、各プールのコピーの数を3に設定することをお勧めします。

最後に、CEPH分散ストレージ展開アーキテクチャを下の図に示します。

ユーザーアプリケーションレイヤー

多くの企業では、サービスの高い可用性が関与しています。一般的な高可用性は、VIP（Vitrual IP）によって達成されます。 VIPは、IPのような実際のネットワークインターフェイス（ネットワークカード）には対応していません。仮想IPアドレスであるため、その機能を使用して、サービスのフォールトトレランスと移行を実現できます。

一般的なノードでは、VIP構成は非常に単純であり、大きな制限はありません。ただし、OpenStackインスタンスでは、1つのIPがポートデバイスに対応しています。さらに、中性子には「許可されたアドレスペア」制限があります。この関数では、IPを接続できるように、ポートのMAC/IPが相互に対応する必要があります。ポートデバイスの操作は、次の機能を達成できます。

ポートデバイスは、許可されたアドレスペアの複数のセットを追加し、ポートを介して複数のIPを接続できるようにします。
1つのIPは、MACアドレスの複数のセットに対応しています。
1つのMACアドレスは、複数のIPに対応しています

さらに、OpenStackによって作成されたインスタンスでは、次の方法を使用できます。

VIPポートデバイスを作成します（VIPが再び割り当てられないようにします）
ポートデバイスのアドレスペアを更新します

最初のステップは、ポートデバイスを作成することです

#Source admin-openrc.sh //テナント環境変数をインポートします 
 #openStackネットワークリスト//既存のネットワークを表示し、ネットワークを選択してポートデバイスを作成する 
 #openstack subnet list //ネットワークの下にサブネットが存在するものを表示し、ポートデバイスが配置されているサブネットを選択します 
 #openstackポート作成  -network network_name -fixed-ip subnet = subnet_name、    
 ip-address = ip port_name  
 #OpenStackポートショーポート_NAME

現時点では、ポートデバイスが作成されていますが、ポートデバイスは、確立する必要があるインスタンスとは何の関係もありません。インスタンスでVIPを作成することはできません。その理由は次のとおりです

#Neutronポートリスト| GREP INSTANCE-IP // VIPを構成する必要があるインスタンスのポートIDを見つけます

このポートの詳細をご覧ください

#Neutronポートショー17B580E8-1733-4E2E-B248-CDE4863F4985

現時点では、adocation_address_pairsは空です。このインスタンスでVIPが作成されていても、そのMAC/IPは対応せず、動作できません。次に、2番目のステップに進む必要があります。つまり、ポートのAldoct_address_pairs情報を更新する必要があります

#Neutron PORT-Update Port-ID -Allowed_Address_Pair List-True Type = dict ip_address = ip

例えば

#Neutronポート -更新17B580E8-1733-4E2E-B248-CDE4863F4985  
 -allowed_address_pairs list = true type = dict ip_address = 172.24.1.202

インスタンスポート情報を確認します

#Neutronポートショー17B580E8-1733-4E2E-B248-CDE4863F4985

この時点で、仮想マシンにVIPを作成すると、正常に機能します。

運用およびメンテナンスプラットフォームの構築

監視は、操作とメンテナンス全体の中で最も重要な部分、さらには製品のライフサイクル全体です。事前に障害を見つけることはタイムリーな警告であり、その後、ポジショニングの問題を追跡するために詳細なデータが提供されます。現在、業界では多くの優れたオープンソース製品があります。いくつかのオープンソース監視システムを選択することは、時間を節約し、労力を節約するソリューションであり、最も効率的なソリューションです。

Kollaを使用して、OpenStack Cloudプラットフォームの展開と管理をコンテナ化することが、主流のトレンドになりました。ここでは、OpenStack Cloudプラットフォームのコンテナ化された展開と管理に基づいて、クラウドプラットフォームに関連する操作およびメンテナンスプラットフォームの構築について説明します。

監視目標

まず、監視とは何か、監視の重要性、監視の目標を理解しましょう。もちろん、すべての産業、企業、企業、およびポジションは異なり、監視の理解も異なります。ただし、特定の監視技術の使用ではなく、会社のビジネスの観点から監視を検討する必要があることに注意する必要があります。

監視の目的は次のとおりです。

1）システムの中断のないリアルタイム監視：実際、システムの途切れないリアルタイム監視です（これは監視です）。
2）システムの現在のステータスに関するリアルタイムフィードバック：特定のハードウェアまたは特定のシステムを監視する場合、システムの現在のステータスをリアルタイムで確認できる必要があります。これは正常、異常、または障害です。
3）サービスの信頼性とセキュリティを確保する：監視の目的は、システム、サービス、および企業の通常の運用を確保することです。
4）事業の継続的かつ安定した操作を確保する：監視が非常にうまく行われた場合、障害がある場合でも、できるだけ早く障害アラームを受け取り、できるだけ早く処理することができます。

監視システムの階層化

監視は、さまざまな専門的な操作とメンテナンスの調整された改善に依存します。監視システムを階層化して分類することにより、各プロのラインは焦点を合わせて監視インジケーターを濃縮します。監視するオブジェクトには、以下の図に示すように、インフラストラクチャハードウェアやアプリケーションソフトウェアなどが含まれます。

ハードウェア機能層：スイッチ、ルーター、ロードバランスデバイス、ファイアウォール、サーバー（ハードディスク、CPU、メモリ、ネットワークカード）など。
クラウドプラットフォームレイヤー：ログ、データベース、メッセージキュー、オペレーティングシステム、OpenStack Services、Ceph Storage、Dockerコンテナ、システム、アプリケーションロードなど。
アプリケーションレイヤー：仮想マシン、データボリューム、仮想ネットワークカードなど。

監視方法

通常、システムが実行されると、オペレーティングシステムがシステムログを生成し、アプリケーションがアプリケーションアクセスログ、エラーログ、実行ログ、ネットワークログを生成します。 EFKを使用してログを監視できます。ログ監視の場合、最も一般的な要件は、収集、ストレージ、クエリ、ディスプレイです。

ログの監視に加えて、システムの健康とアプリケーションをリアルタイムで監視する必要もあります。監視目標が異なると、監視方法が異なります。仮想マシン、ミラー、データボリューム、仮想ネットワークカードなどのOpenStackクラウドリソースの監視は、OpenStack独自のCeilメーター+Gnocchi+AODHサービスによって自然に行うことができます（PS：CEILOMETORメーターは、収集したデータをGNOCCHIに引き渡してデータの凝集を行い、最終的にグラファナを使用してレポートを表示します）。

OpenStack Cloudプラットフォームは、Kollaコンテナ化された展開と運用管理に基づいています。したがって、Dockerコンテナ、オペレーティングシステムの負荷、ストレージスペースなど、オペレーティングとメンテナンスの監視と警告に使用する必要があります。当然、TPIGスタックが出てきました。

TPIGスタックとは何ですか。つまり、Telegraf + InfluxDB + Grafana + Prometheusで構成される一連の操作およびメンテナンス監視ツールです。それらの間の関係は次のとおりです。

Prometheus/Telegraf（データの収集） - > influxDb（データの保存） - > grafana（show data）

説明：

プロメテウスとテレグラフは同時に展開する必要はありません。ニーズに応じて両方を展開するか、そのいずれかを選択することもできます。

Kollaコミュニティは、デフォルトで次のオープンソースツールまたはソリューションをサポートしています。最も重要なことは、それらをどのように使用し、改善するかです。

ログ収集と分析の処理のためのオープンソースソリューションはEFKスタックです：Fluentd/filebeat + elasticsearch + kibana
パフォーマンスの獲得および分析処理のためのオープンソースソリューションには、TPIGスタック：Telegraf + InfluxDB + Grafana + Prometheusが含まれます

監視方法

監視オブジェクトを理解する：監視したいオブジェクトを理解していますか？たとえば、ハードドライブのIOPS？
オブジェクトパフォーマンスインジケーター：どのような属性を監視しますか？たとえば、CPUの使用、ロード、ユーザー状態、カーネル状態、およびコンテキストスイッチング。
アラームしきい値定義：障害の計算方法は？アラームとは何ですか？たとえば、CPUの負荷数はどれくらい高くなりますか？ユーザーの状態とカーネル状態はどれくらいですか？
トラブルシューティングプロセス：障害アラームを受け取ったときにどのように対処しますか？これ以上効率的な処理プロセスはありますか？

監視プロセス

データ収集：Telegraf/Prometheusなどによるシステムとアプリケーションのデータ収集。
データストレージ：監視データは、MySQL、InfluxDB、または他のデータベースに保存されます。
データ分析：その後障害を分析する必要がある場合、EFKスタックはグラフィックと時間、その他の関連情報を提供し、障害を決定します。
データ表示：Webインターフェイスディスプレイ。
監視アラーム：電話アラーム、電子メールアラーム、WeChatアラーム、SMSアラーム、アラームアップグレードメカニズムなど（どのようなアラームが利用可能かに関係なく）。
アラーム処理：アラームが受信された場合、次のような障害のレベルに応じて処理する必要があります。障害のレベルによると、関連する担当者と協力して迅速な処理を行います。

監視アラーム

監視されたオブジェクトが特定のしきい値を超えるか、特定のサービスで異常が発生する場合、電子メール、テキストメッセージ、またはWeChatが関連する担当者に自動的に送信され、警告が表示されます。

インシデント緊急対応

操作とメンテナンスの最も基本的な指標は、システムの可用性を確保することであり、緊急回復の適時性はシステムの可用性の重要な指標です。一般的に言えば、次のような多くの緊急回復方法があります。

サービスの全体的なパフォーマンスが劣化または異常な場合は、サービスの再起動を検討できます。
アプリケーションが変更されたため、バックせん断の変更の必要性があるかどうかを検討できます。
リソースが不十分な場合、緊急能力の拡大を考慮することができます。
アプリケーションのパフォーマンスの問題については、アプリケーションパラメーターとログパラメーターの調整を検討できます。
データベースがビジーである場合は、データベーススナップショット分析を介してSQLを最適化することを検討できます。
アプリケーション機能の設計が正しくない場合は、関数メニューを緊急に閉じることを検討できます。
もっとたくさんあります...

あなたが見て考えていることのいくつか

実際には、いくつかのイデオロギーとの多くの出会いがあります。 Hadoop/Spark Big Data Businessは仮想マシンで実行され、さまざまな落とし穴がオンラインで表示されます。たとえば、ディスクIOのパフォーマンスは非常に貧弱で、仮想マシンはホストリソースを押収し、CPUの使用量が700％を超え、最終的に私が掘ったピットに落ちます。

クラウドコンピューティングの本質は仮想化であることに注意する必要があります。仮想化の本質は仮想であり、多くの、つまり物理的なコンピューティングリソース、ネットワークリソース、ストレージリソースなどは、複数の論理リソース（KVM、OpenVswitch、CEPHなど）に仮想化され、リソーススケジューリングシステム（OpenStackなど）によってユーザーに使用を提供するように抽象化されます。ビッグデータの本質は、複数のコンピューティング、ストレージ、ネットワークリソースの統合された管理を統合してビッグデータサービスに提供する多元的なものです。

OpenStackは、仮想マシンと裸の金属を統一された方法で管理できます。推奨されるアプローチは、仮想マシンではなく裸の金属にビッグデータを配置することです。それがテクノロジーの性質に反する場合、プロセスは痛みを伴う運命にあります。

一部のユーザーは、クラウドやクラウドを使用するときに使用するソリューションを心配することがよくありますか？たとえば、OpenVswitchまたはLinuxbridgeを使用していますか？ VLANまたはVXLAN、GREを使用していますか？ CephまたはGlusterfsを使用して、商用ストレージ？二次開発などを行う必要がありますか？テクノロジーが要件を決定したことはありませんが、要件が技術的な選択を決定することに注意してください。同様に、使用する技術は実際のニーズによって決定されるべきです。あなたにとって一番いいのはです。両方に独自の利点と短所があるとしか言えません。ユーザーが行う必要があるのは、最も危険なソリューションを回避し、実際のニーズに応じて最も明白な利点を持つソリューションを選択することです。

OpenStackを使用する準備をするときは、OpenStackが知識集約型のオープンソースクラウドフレームワークであることを明確にしてください。あらゆる面で必要な技術的な才能と技術的準備は非常に広範です。企業は通常、才能の欠如の問題に直面しています。一方で、経験豊富な人々を外部から募集することは困難であり、他方では、企業が内部の才能を培うことは時間がかかり、労働集約的です。エンタープライズがOpenStackを独自の使用のためにプライベートクラウドとしてのみ使用している場合、その機能的要件やビジネスは、高価なVMwareの代わりに仮想マシンサービスを提供するなど、複雑ではない場合、一般に二次開発は必要ありません。それどころか、OpenStackがサードパーティのユーザーにクラウド製品として提供されている場合、または複雑なビジネスニーズを満たす場合、統一されたクラウドリソース管理、リソースロジックスケジューリング、操作とメンテナンスの監視とアラーム、IAAS+SAAS統一サポートなど、実際には、OpenStackが存在しているため、Alibaba Cloudはedaintim forestimを使用しているため、Alibaba Cloudはedaintimを使用していますダッシュボード、そして最終的にデッドループに落ちました。

やっと

テクノロジーの進化により、プラットフォームの複雑さ +ユーザーの簡素化の傾向がますます明らかになります。これには、最終的にユーザーに提示されたシステムがミニマリストである必要があります。 OpenStackはこの側面に向かって機能し、企業ユーザーの緊急のニーズを現実的な運用性に変えると信じています。

最後に、OpenStackと、クラウドコンピューティングへの扉を開くように私を導いた元会社のリーダーと同僚に感謝したいと思います！同時に、いつか、OpenStack Cloud Computingが大企業だけで楽しめる輸入製品から普通の起業家に参加できることを願っています。

OpenStackは若い男であり、ずっと行く理由があります！

著者の紹介：

Xu Chao、OpenStack、Kubernetes、Docker、CI/CDの開業医および学習者、「OpenStack Best Practices -Testing and CI/CD」の著者、およびOpenStack Open Sourceコミュニティの参加者。

<<: Red Hat Enterprise Linux 7.6がリリースされ、ハイブリッドクラウドのイノベーションがさらに最適化されました。

>>: 手頃な価格の有機野菜が天猫双十一に登場、アリババクラウドIoTが強力なツールに