Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

ハイパーコンバージドインフラストラクチャーガイド

Red Hat OpenStack Platform 13

Red Hat OpenStack Platform オーバークラウドにおけるハイパーコンバージドインフラストラクチャーの設定についての理解

概要

本ガイドでは、Red Hat OpenStack Platform のハイパーコンバージェンスの実装について説明します。この実装では、Compute サービスと Ceph Storage サービスが同じホストに配置されます。

前書き

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
  7. Submit をクリックします。

第1章 Red Hat OpenStack Platform ハイパーコンバージドインフラストラクチャーの設定およびデプロイ

Red Hat OpenStack Platform (RHOSP) ハイパーコンバージドインフラストラクチャー (HCI) は、ハイパーコンバージドノードで構成されます。リソースの使用率を最適化するために、サービスがこのハイパーコンバージドノード上で共存します。RHOSP HCI では、Compute サービスとストレージサービスがハイパーコンバージドノード上で共存します。ハイパーコンバージドノードのみのオーバークラウド、またはハイパーコンバージドノードを通常のコンピュートノードおよび Ceph Storage ノードと混在させたオーバークラウドをデプロイすることが可能です。

注記

Red Hat Ceph Storage をストレージプロバイダーとして使用する必要があります。

ヒント
  • Ceph のメモリー設定を自動的に調整するには、ceph-ansible 3.2 以降を使用します。
  • BlueStore のメモリー処理機能を利用するには、BlueStore を HCI デプロイメントのバックエンドとして使用します。

オーバークラウド上に HCI を作成およびデプロイし、オーバークラウドのネットワーク機能仮想化などのその他の機能と統合し、ハイパーコンバージドノード上の Compute サービスと Red Hat Ceph Storage サービス両方のパフォーマンスを最適な状態にするには、以下の手順を実施する必要があります。

  1. ハイパーコンバージドノード向けの事前定義されたカスタムオーバークラウドロール ComputeHCI を準備する。
  2. リソース分離を設定する。
  3. 利用可能な Red Hat Ceph Storage パッケージを確認する。
  4. HCI オーバークラウドをデプロイする。

1.1. 前提条件

  • アンダークラウドをデプロイしている。アンダークラウドのデプロイ方法についての説明は、『director のインストールと使用方法』を参照してください。
  • お使いの環境で、RHOSP Compute および Red Hat Ceph Storage の要件を満たすノードをプロビジョニング可能である。詳しくは、『Director Installation and Usage』の「Basic overcloud deployment」を参照してください。
  • 環境内の全ノードを登録している。詳しくは、「ノードの登録」を参照してください。
  • 環境内の全ノードがタグ付けされている。詳しくは、「ノードの手動でのタグ付け」を参照してください。
  • Compute サービスおよび Ceph OSD サービスに使用するノード上のディスクをクリーンアップしている。詳しくは、「Ceph Storage ノードのディスクのクリーニング」を参照してください。
  • オーバークラウドノードを Red Hat コンテンツ配信ネットワークまたは Red Hat Satellite サーバーに登録するための準備を行っている。詳しくは、『Advanced Overcloud Customization』の「Ansible-based overcloud registration」を参照してください。

1.2. ハイパーコンバージドノード向けのオーバークラウドロールの準備

ノードをハイパーコンバージドとして指定するには、ハイパーコンバージドロールを定義する必要があります。Red Hat OpenStack Platform (RHOSP) は、ハイパーコンバージドノード向けの事前定義されたロール ComputeHCI を提供します。このロールにより、Compute サービスと Ceph オブジェクトストレージデーモン (OSD) サービスを共存させ、同じハイパーコンバージドノード上にまとめてデプロイすることができます。

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. stackrc ファイルを取得します。

    [stack@director ~]$ source ~/stackrc
  3. オーバークラウドに使用するその他のロールに加えて ComputeHCI ロールが含まれる新たなカスタムロールデータファイルを生成します。以下の例では、ロールデータファイル roles_data_hci.yaml を生成します。これには、ControllerComputeHCICompute、および CephStorage ロールが含まれます。

    (undercloud)$ openstack overcloud roles \
     generate -o /home/stack/templates/roles_data_hci.yaml \
      Controller ComputeHCI Compute CephStorage
    注記

    生成されたカスタムロールデータファイルの ComputeHCI ロール用に一覧表示されるネットワークには、Compute サービスと Storage サービスの両方に必要なネットワークが含まれます。以下に例を示します。

    - name: ComputeHCI
      description: |
        Compute node role hosting Ceph OSD
      tags:
        - compute
      networks:
        InternalApi:
          subnet: internal_api_subnet
        Tenant:
          subnet: tenant_subnet
        Storage:
          subnet: storage_subnet
        StorageMgmt:
          subnet: storage_mgmt_subnet
  4. network_data.yaml ファイルのローカルコピーを作成し、コンポーザブルネットワークをオーバークラウドに追加します。network_data.yaml ファイルは、デフォルトのネットワーク環境ファイル /usr/share/openstack-tripleo-heat-templates/environments/* と対話し、ComputeHCI ロール用に定義したネットワークをハイパーコンバージドノードに関連付けます。詳しい情報は、『オーバークラウドの高度なカスタマイズ』「カスタムコンポーザブルネットワークの追加」を参照してください。
  5. Red Hat Ceph Storage のパフォーマンスを向上させるには、network_data.yaml のローカルコピーでジャンボフレーム用に Storage および StorageMgmt ネットワーク両方の MTU 設定を 9000 に更新します。詳細は、「Configuring MTU Settings in Director」および「Configuring jumbo frames」を参照してください。
  6. ハイパーコンバージドノード向けの computeHCI オーバークラウドフレーバーを作成します。

    (undercloud)$ openstack flavor create --id auto \
     --ram <ram_size_mb> --disk <disk_size_gb> \
     --vcpus <no_vcpus> computeHCI
    • <ram_size_mb> をベアメタルノードの RAM (MB 単位) に置き換えます。
    • <disk_size_gb> をベアメタルノード上のディスク容量 (GB 単位) に置き換えます。
    • <no_vcpus> をベアメタルノードの CPU 数に置き換えます。
    注記

    これらの属性は、インスタンスのスケジューリングには使用されません。ただし Compute スケジューラーは、ディスク容量を使用してルートパーティションのサイズを決定します。

  7. ノード一覧を取得して UUID を識別します。

    (undercloud)$ openstack baremetal node list
  8. ハイパーコンバージドとして指定する各ベアメタルノードに、カスタムの HCI リソースクラスをタグ付けします。

    (undercloud)$ openstack baremetal node set \
     --resource-class baremetal.HCI <node>

    <node> をベアメタルノードの ID に置き換えてください。

  9. computeHCI フレーバーをカスタムの HCI リソースクラスに関連付けます。

    (undercloud)$ openstack flavor set \
    --property resources:CUSTOM_BAREMETAL_HCI=1 \
    computeHCI

    Bare Metal サービスノードのリソースクラスに対応するカスタムリソースクラスの名前を指定するには、リソースクラスを大文字に変換し、すべての句読点をアンダースコアに置き換え、CUSTOM_ のプレフィックスを追加します。

    注記

    フレーバーが要求できるのは、ベアメタルリソースクラスの 1 つのインスタンスだけです。

  10. 以下のフレーバー属性を設定して、Compute スケジューラーがインスタンスのスケジューリングにベアメタルフレーバー属性を使用するのを防ぎます。

    (undercloud)$ openstack flavor set \
     --property resources:VCPU=0 \
     --property resources:MEMORY_MB=0 \
     --property resources:DISK_GB=0 computeHCI
  11. 以下のパラメーターを node-info.yaml ファイルに追加して、ハイパーコンバージドノードおよびコントローラーノードの数およびハイパーコンバージドおよびコントローラーに指定するノード用に使用するフレーバーを指定します。

    parameter_defaults:
      OvercloudComputeHCIFlavor: computeHCI
      ComputeHCICount: 3
      OvercloudControlFlavor: baremetal
      ControllerCount: 3

1.2.1. ルートディスクの定義

ノードで複数のディスクが使用されている場合には、director はプロビジョニング時にルートディスクを特定する必要があります。たとえば、ほとんどの Ceph Storage ノードでは、複数のディスクが使用されます。デフォルトのプロビジョニングプロセスでは、director はルートディスクにオーバークラウドイメージを書き込みます。

以下のプロパティーを定義すると、director がルートディスクを特定するのに役立ちます。

  • model (文字列): デバイスの ID
  • vendor (文字列): デバイスのベンダー
  • serial (文字列): ディスクのシリアル番号
  • hctl (文字列): SCSI のホスト、チャンネル、ターゲット、Lun
  • size (整数):デバイスのサイズ (GB 単位)
  • wwn (文字列): 一意のストレージ ID
  • wwn_with_extension (文字列): ベンダー拡張子を追加した一意のストレージ ID
  • wwn_vendor_extension (文字列): 一意のベンダーストレージ ID
  • rotational (ブール値): 回転式デバイス (HDD) には true、そうでない場合 (SSD) には false。
  • name (文字列): デバイス名 (例: /dev/sdb1)。
  • by_path (文字列): デバイスの一意の PCI パス。デバイスの UUID を使用しない場合は、このプロパティーを使用。
重要

name プロパティーは、永続的なデバイス名が付いたデバイスにのみ使用します。他のデバイスのルートディスクを設定する際に、name を使用しないでください。この値は、ノードの起動時に変更される可能性があります。

シリアル番号を使用してルートデバイスを指定するには、以下の手順を実施します。

手順

  1. 各ノードのハードウェアイントロスペクションからのディスク情報を確認します。以下のコマンドを実行して、ノードのディスク情報を表示します。

    (undercloud) $ openstack baremetal introspection data save 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0 | jq ".inventory.disks"

    たとえば、1 つのノードのデータで 3 つのディスクが表示される場合があります。

    [
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sda",
        "wwn_vendor_extension": "0x1ea4dcc412a9632b",
        "wwn_with_extension": "0x61866da04f3807001ea4dcc412a9632b",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f380700",
        "serial": "61866da04f3807001ea4dcc412a9632b"
      }
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sdb",
        "wwn_vendor_extension": "0x1ea4e13c12e36ad6",
        "wwn_with_extension": "0x61866da04f380d001ea4e13c12e36ad6",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f380d00",
        "serial": "61866da04f380d001ea4e13c12e36ad6"
      }
      {
        "size": 299439751168,
        "rotational": true,
        "vendor": "DELL",
        "name": "/dev/sdc",
        "wwn_vendor_extension": "0x1ea4e31e121cfb45",
        "wwn_with_extension": "0x61866da04f37fc001ea4e31e121cfb45",
        "model": "PERC H330 Mini",
        "wwn": "0x61866da04f37fc00",
        "serial": "61866da04f37fc001ea4e31e121cfb45"
      }
    ]
  2. ノード定義の root_device パラメーターに変更を加えます。以下の例では、ルートデバイスをシリアル番号が 61866da04f380d001ea4e13c12e36ad6 のディスク 2 に設定する方法を説明します。

    (undercloud) $ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
    注記

    各ノードの BIOS を設定して、選択したルートディスクからのブートを含めるようにします。最初にネットワークからのブートを試み、次にルートディスクからのブートを試みるように、ブート順序を設定します。

director は、ルートディスクとして使用する特定のディスクを把握します。openstack overcloud deploy コマンドを実行すると、director はオーバークラウドをプロビジョニングし、ルートディスクにオーバークラウドのイメージを書き込みます。

1.3. ハイパーコンバージドノード上におけるリソース分離の設定

ハイパーコンバージドノード上で Ceph OSD サービスと Compute サービスを共存させると、お互いが同じホスト上に存在することを認識しないため、Red Hat Ceph Storage サービスと Compute サービス間でリソースの競合が発生するリスクがあります。リソースの競合が発生すると、サービスのパフォーマンスが低下し、ハイパーコンバージェンスの利点が打ち消される可能性があります。

Ceph サービスと Compute サービスの両方にリソースの分離を設定して、競合が発生を防ぐ必要があります。

手順

  1. (オプション) Compute 環境ファイルに以下のパラメーターを追加して、自動生成される Compute 設定を上書きします。

    parameter_defaults:
      ComputeHCIParameters:
        NovaReservedHostMemory: <ram>
        NovaCPUAllocationRatio: <ratio>
    • <ram> を、ハイパーコンバージドノード上で Ceph OSD サービスおよびインスタンスのオーバーヘッド用に確保する RAM 容量 (MB 単位) に置き換えます。
    • <ratio> を、インスタンスをデプロイするコンピュートノードを選択する際に Compute スケジューラーが使用すべき比率に置き換えます。

      自動生成される Compute 設定についての詳細は、「Compute サービス用に確保する CPU およびメモリーリソースの自動生成プロセス」を参照してください。

  2. Red Hat Ceph Storage 用にメモリーリソースを確保するには、/home/stack/templates/storage-container-config.yamlis_hcitrue に設定します。

    parameter_defaults:
      CephAnsibleExtraConfig:
        is_hci: true

    この設定により、ceph-ansible は Red Hat Ceph Storage 用のメモリーリソースを確保することができ、HCI デプロイメントの osd_memory_target パラメーター設定を自動的に調整することで、Ceph OSD によるメモリー増大を低減することができます。

    警告

    Red Hat では、ceph_osd_docker_memory_limit パラメーターを直接上書きすることは推奨しません。

    注記

    FileStore または BlueStore どちらのバックエンドが使用されていても、ceph-ansible 3.2 では、ceph_osd_docker_memory_limit は Ansible の検出したホストの最大メモリーに自動的に設定されます。

  3. (オプション) デフォルトでは、ceph-ansible は Ceph OSD ごとに 1 つの仮想 CPU を確保します。Ceph OSD ごとに複数の CPU が必要な場合は、以下の設定を /home/stack/templates/storage-container-config.yaml に追加します。

    parameter_defaults:
      CephAnsibleExtraConfig:
        ceph_osd_docker_cpu_limit: <cpu_limit>

    <cpu_limit> を各 Ceph OSD 用に確保する CPU 数に置き換えます。

    ハードウェアおよびワークロードに基づいて CPU リソースを調整する方法の詳細は、『Red Hat Ceph Storage Hardware Selection Guide』を参照してください。

  4. (オプション) 以下のパラメーターを Ceph 環境ファイルに追加することで、Ceph OSD の削除時に Red Hat Ceph Storage のバックフィルとリカバリーの操作の優先度を低くします。

    parameter_defaults:
      CephConfigOverrides:
        osd_recovery_op_priority: <priority_value>
        osd_recovery_max_active: <no_active_recovery_requests>
        osd_max_backfills: <max_no_backfills>
    • <priority_value> を、OSD クライアント OP の優先度と相対的に、リカバリーの操作の優先度に置き換えます。
    • <no_active_recovery_requests> を、1 OSD あたりの 1 回にアクティブなリカバリー要求の件数に置き換えます。
    • <max_no_backfills> を、単一の OSD との間で許容されるバックフィルの最大数に置き換えます。

      デフォルトの Red Hat Ceph Storage のバックフィルおよびリカバリーオプションに関する詳細は、「Red Hat Ceph Storage のバックフィルとリカバリーの操作」を参照してください。

1.3.1. Compute サービス用に確保する CPU およびメモリーリソースの自動生成プロセス

director の提供するデフォルトのプラン環境ファイルにより、デプロイメント時のハイパーコンバージドノードのリソース制約が設定されます。このプラン環境ファイルは、OpenStack Workflow に以下のプロセスを実施するように指示します。

  1. ハードウェアノードの検査時に収集したハードウェアイントロスペクションデータを取得する。
  2. そのデータに基づき、ハイパーコンバージドノード上の Compute の最適な CPU およびメモリー割り当て負荷を算出する。
  3. これらの制約を設定し Compute に CPU/メモリーリソースを確保するのに必要なパラメーターを自動生成する。これらのパラメーターは、plan-environment-derived-params.yaml ファイルの hci_profile_config セクションで定義されます。
注記

Compute の reserved_host_memory および cpu_allocation_ratio の設定値を算出するのに、各ワークロードプロファイルの average_guest_memory_size_in_mb および average_guest_cpu_utilization_percentage パラメーターが使用されます。

Compute 環境ファイルに以下のパラメーターを追加して、自動生成される Compute 設定を上書きすることができます。

自動生成される nova.conf パラメーターCompute 環境ファイルのオーバーライド説明

reserved_host_memory

parameter_defaults:
  ComputeHCIParameters:
    NovaReservedHostMemory: 181000

ハイパーコンバージドノード上で、Ceph OSD サービスおよびゲストインスタンスごとのオーバーヘッドに確保する RAM 容量を設定します。

cpu_allocation_ratio

parameter_defaults:
  ComputeHCIParameters:
    NovaCPUAllocationRatio: 8.2

インスタンスをデプロイするコンピュートノードを選択する際に Compute スケジューラーが使用すべき比率を設定します。

これらのオーバーライドは、ComputeHCI ロールを使用するすべてのノード (つまり、すべてのハイパーコンバージドノード) に適用されます。NovaReservedHostMemory および NovaCPUAllocationRatio の最適値を手動で決定する方法についての詳細は、「OpenStack Workflow Compute の CPU およびメモリーの計算」を参照してください。

ヒント

以下のスクリプトを使用して、ハイパーコンバージドノードの NovaReservedHostMemory および NovaCPUAllocationRatio の適切な基準値を算出することができます。

nova_mem_cpu_calc.py

1.3.2. Red Hat Ceph Storage のバックフィルとリカバリーの操作

Ceph OSD が削除されると、Red Hat Ceph Storage はバックフィルおよびリカバリー操作を使用してクラスターをリバランスします。Red Hat Ceph Storage は配置グループポリシーに従って、データのコピーを複数保管するためにこの操作を実行します。これらの操作は、システムリソースを使用します。Red Hat Ceph Storage クラスターに負荷がかかっている場合、リソースがバックフィルおよびリカバリーに回されるので、パフォーマンスが低下します。

OSD 削除時のこのパフォーマンスへの影響を軽減するには、バックフィルおよびリカバリー操作の優先度を低くすることができます。この手法のマイナス面は、データのレプリカがより少ない状態が長くなるので、データがリスクにさらされる可能性が若干高くなることです。

以下の表で説明するパラメーターが、バックフィルおよびリカバリー操作の優先度を設定するのに使用されます。

パラメーター詳細デフォルト値

osd_recovery_op_priority

OSD クライアントの操作に関して、リカバリー操作の優先度を設定します。

3

osd_recovery_max_active

同時に要求できる 1 OSD あたりのアクティブなリカバリー要求の数を設定します。要求が増えるにつれてリカバリーは加速されますが、それらの要求によりクラスターにかかる負荷が増大します。レイテンシーを低くするには、このパラメーターを 1 に設定します。

3

osd_max_backfills

単一の OSD との間で許容されるバックフィルの最大数を設定します。

1

1.4. Ceph Storage のデプロイメント前の検証

オーバークラウドのデプロイメントが失敗しないようにするには、必要なパッケージがサーバーに存在することを確認します。

1.4.1. ceph-ansible パッケージバージョンの確認

アンダークラウドには Ansible ベースの検証が含まれ、これを実行してオーバークラウドをデプロイする前に潜在的な問題を特定することができます。これらの検証は、典型的な問題が発生する前にそれらを特定し、オーバークラウドのデプロイメントの失敗を回避するのに役立ちます。

手順

ceph-ansible パッケージの修正バージョンがインストールされていることを確認してください。

$ ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/openstack-tripleo-validations/validations/ceph-ansible-installed.yaml

1.4.2. 事前にプロビジョニングされたノード用のパッケージの確認

オーバークラウドのデプロイメントで事前にプロビジョニングされたノードを使用する場合には、Ceph サービスをホストするオーバークラウドノードに必要なパッケージがサーバーにあることを確認することができます。

事前にプロビジョニングされたノードの詳細は、「事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定」を参照してください。

手順

サーバーに必要なパッケージが含まれていることを確認します。

ansible-playbook -i /usr/bin/tripleo-ansible-inventory /usr/share/openstack-tripleo-validations/validations/ceph-dependencies-installed.yaml

1.5. HCI オーバークラウドのデプロイ

HCI 設定が完了した後に、オーバークラウドをデプロイする必要があります。

重要

Red Hat OpenStack Platform (RHOSP) HCI 環境をデプロイする際には、インスタンス HA を有効にしないでください。Red Hat Ceph Storage を使用したハイパーコンバージド RHOSP デプロイメントでインスタンス HA を使用する場合は、Red Hat の担当者にお問い合わせください。

前提条件

手順

  • その他の環境ファイルと共に新しいロールファイルおよび環境ファイルをスタックに追加して、HCI オーバークラウドをデプロイします。

    (undercloud)$ openstack overcloud deploy --templates \
      -e [your environment files] \
      -r /home/stack/templates/roles_data_hci.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml
      -e /home/stack/templates/storage-config.yaml \
      -e /home/stack/templates/storage-container-config.yaml \
      -n /home/stack/templates/network_data.yaml \
      [-e /home/stack/templates/ceph-backfill-recovery.yaml \ ]
      --ntp-server pool.ntp.org

    デプロイメントコマンドに /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml を含めることで、すべてのデフォルト設定でコンテナー化された Red Hat Ceph クラスターをデプロイするベース環境ファイルが追加されます。詳しくは、『コンテナー化された Red Hat Ceph を持つオーバークラウドのデプロイ』を参照してください。

注記

デプロイメントで Single Root Input/Output Virtualization (SR-IOV) を使用する場合は、デプロイメントコマンドに以下のオプションを追加します。

-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml
-e /home/stack/templates/network-environment.yaml
ヒント

アンサー ファイルを使用して、デプロイメントに追加する環境ファイルを指定することも可能です。詳しくは、『director のインストールと使用方法』「オーバークラウドデプロイメントへの環境ファイルの追加」を参照してください。

1.6. OpenStack Workflow Compute の CPU およびメモリーの計算

OpenStack Workflow は CPU とメモリーに最適な設定を計算し、その結果を使用してパラメーター NovaReservedHostMemory および NovaCPUAllocationRatio に反映させます。

NovaReservedHostMemory

NovaReservedHostMemory パラメーターは、ホストノードに確保するメモリー容量 (MB 単位) を設定します。ハイパーコンバージドノードに適切な値を決定するには、 各 OSD が 3 GB のメモリーを消費すると仮定します。メモリーが 256 GB で OSD が 10 の場合には、Ceph に 30 GB のメモリーを割り当てて、Compute に 226 GB 残します。このメモリー容量のノードでは、たとえば、それぞれ 2 GB のメモリーを使用するインスタンスを 113 台ホストすることができます。

ただし、ハイパーバイザー 用に、インスタンス 1 台あたりの追加のオーバーヘッドを考慮する必要があります。このオーバーヘッドが 0.5 GB と仮定すると、同じノードでは、90 インスタンスしかホストできません。これは、226 GB を 2.5 GB で割ったものです。ホストノードに確保するメモリー容量 (Compute サービスが使用してはならないメモリー) は以下のように算出します。

(In * Ov) + (Os * RA)

ここで、

  • In: インスタンス数
  • Ov: インスタンス 1 台あたりに必要なオーバヘッド用のメモリー容量
  • Os: ノード上の OSD 数
  • RA: 各 OSD に割り当てる必要のある RAM 容量

90 台のインスタンスの場合には、(90 * 0.5) + (10 * 3) = 75 GB という計算になります。Compute サービスには、この値を MB 単位で指定します (75000)。

以下の Python コードにより、この計算を行うことができます。

left_over_mem = mem - (GB_per_OSD * osds)
number_of_guests = int(left_over_mem /
    (average_guest_size + GB_overhead_per_guest))
nova_reserved_mem_MB = MB_per_GB * (
    (GB_per_OSD * osds) +
    (number_of_guests * GB_overhead_per_guest))

NovaCPUAllocationRatio

Compute スケジューラーは、インスタンスをデプロイするコンピュートノードを選択する際に NovaCPUAllocationRatio を使用します。デフォルトでは、この値は 16.0 (16:1) です。ノードに 56 のコアがある場合には、Compute スケジューラーは 896 の仮想 CPU を使用するのに十分なインスタンスをノードにスケジュールすることになります。この値を超えると、そのノードはそれ以上インスタンスをホストできないと見なされます。

ハイパーコンバージドノードの適切な NovaCPUAllocationRatio を決定するには、各 Ceph OSD が少なくとも 1 コアを使用すると仮定します (ワークロードが I/O 集中型で、SSD を使用しないノード上にある場合を除く)。56 コア、10 OSD のノードでは、この計算で 46 コアが Compute に確保されます。各インスタンスが割り当てられた CPU を 100 パーセント使用すと仮定すると、この比率は単にインスタンスの仮想 CPU 数をコア数で除算した値となります (46 / 56 = 0.8)。ただし、通常インスタンスは割り当てられた CPU を 100 パーセント使用することはないため、必要なゲスト仮想 CPU の数を決定する際には、予想される使用率を考慮に入れて NovaCPUAllocationRatio を高くすることができます。

したがって、インスタンスが仮想 CPU の 10 パーセント (または 0.1) のみを使用すると予想できる場合には、インスタンス用の仮想 CPU 数は 46 / 0.1 = 460 の式で表すことができます。この値をコア数 (56) で除算すると、比率は約 8 に増えます。

以下の Python コードにより、この計算を行うことができます。

cores_per_OSD = 1.0
average_guest_util = 0.1 # 10%
nonceph_cores = cores - (cores_per_OSD * osds)
guest_vCPUs = nonceph_cores / average_guest_util
cpu_allocation_ratio = guest_vCPUs / cores

1.7. 関連資料

Red Hat OpenStack Platform (RHOSP) に関する詳しい情報は、以下のガイドを参照してください。

第2章 ハイパーコンバージドノードのスケーリング

HCI ノードをスケールアップまたはスケールダウンする場合、コンピュートノードまたは Red Hat Ceph Storage ノードのスケーリングと同じ原則および手法が適用されます。

2.1. HCI 環境におけるハイパーコンバージドノードのスケールアップ

HCI 環境のハイパーコンバージドノードをスケールアップするには、ハイパーコンバージドノードではないノードをスケールアップするのと同じ手順に従います。詳しくは、「オーバークラウドへのノード追加」を参照してください。

注記

新規ノードをタグ付けする場合には、必ず適切なフレーバーを使用するようにしてください。

OSD を Red Hat Ceph Storage クラスターに追加して HCI ノードをスケールアップする方法は、『コンテナー化された Red Hat Ceph を持つオーバークラウドのデプロイ』「OSD の Ceph Storage ノードへの追加」を参照してください。

2.2. HCI 環境におけるハイパーコンバージドノードのスケールダウン

HCI 環境のハイパーコンバージドノードをスケールダウンするには、HCI ノード上の Ceph OSD サービスをリバランスし、HCI ノードからインスタンスを移行し、オーバークラウドからコンピュートノードを削除する必要があります。

手順

  1. HCI ノード上の Ceph OSD サービスを無効にして、リバランスします。HCI ノードまたは Red Hat Ceph Storage ノードを削除する際に、director は Red Hat Ceph Storage クラスターを自的にリバランスしないので、このステップが必要となります。
  2. HCI ノードからインスタンスを移行します。詳細については、『インスタンス作成のための Compute サービスの設定』「コンピュートノード間の仮想マシンインスタンスの移行」を参照してください。
  3. オーバークラウドからコンピュートノードを削除します。詳しくは、「コンピュートノードの削除」を参照してください。