勉強中の雑メモ。玄人向けですよね…
Keystone
Keystone はユーザーを認証するほか、権限付与でも中心的な役割を果たす。
認証によってユーザーのアイデンティティが確認されるが、認証されたユーザーがリクエストできるAPIは権限付与によって決まる。
認証と権限付与のフロー
1. ユーザー名、パスワード、およびスコープ(通常はプロジェクト)を指定することで、ユーザーはKeystoneの認証を受ける。
2. Keystoneが認証情報を受け入れると、ユーザーアカウントに関する情報(プロジェクトのコンテキストやそのプロジェクトにおけるユーザーのロールなど)を含むトークンを生成する。トークンが期限切れにならない限り(デフォルト期限は1時間)、ユーザーはこのトークンを使用し、クラウドにサービスをリクエストできる。
3. NovaにVMの起動を指示したとすると、トークンのIDが X-Auth-Token HTTP ヘッダーに含まれている必要がある。このヘッダーが存在しないか有効なトークンを参照していない場合、"401 Unauthorized"の エラーステータスのレスポンスが返される。
4. Nova は Keystone にアクセスし、トークンを検証する。 Keystone にアクセスするには、Nova は独自の認証情報を使用するか、有効なトークンを提供する必要がある。
5. トークンが有効であり、期限切れでも無効でもないとKeystone が判断すると、ロールとプロジェクトと共に成功コードを返す。
6. この時点でNovaは、トークンが有効であることと、そのトークンに関連付けられているロールを認識しており、その上でVMを開始する権限があるかどうかを判断する(権限付与)。 各サービスには専用のポリシーがあり、APIリクエストを許可できる状況を定義している。
7. (ユーザーのロールのうちの1つがVMを起動できるようポリシーで権限が定義されていた場合は)NovaがVMを起動し、その結果をユーザーに返す。
トークンには、ロール、ユーザー、プロジェクト、ドメインなどのAPIリクエスターに関する情報が含まれているが、これらの項目は特に深い意味を持たないただの名前に過ぎない。意味はサービスのポリシーによって定義される。
各OpenStack サービス、アイデンティティ、コンピュート、ネットワークなどは、専用のアクセスポリシーが設定されている。ポリシーによって、誰がどのAPIリクエストを送信できるのかが決定される。
ポリシールールは、キーと値のペア(キーバリューペア)であり、キー(コロンの左側)がAPI、値は通常リクエスターのロールに基づいたブール式だが、他にもユーザー/プロジェクト/ドメイン情報を含めることもできる。
Nova
各コンポーネントの確認
# openstack compute service list
nova-api: エンドユーザーのコンピュートからのAPIコールを受け付けて応答する。ユーザーの詳細をKeystoneから取得し、ポリシーと比較することでAPIリクエストを検証する。
検証済みのリクエストはconductorに渡される。 通常はAPIリクエストを受信し、Novaに転送する
nova-scheduler: インスタンスが起動や移行されるたびに、コンピュートノードを決定する
nova-conductor: コンピュート上で実行されるnova-compute と常に通信して、特にインスタンスの起動、移行、スナップショットの取得などの⻑時間実行されるタスクやDBへのノード追加も行う
nova-compute: 各コンピュートノードで実行され、インスタンスのライフサイクル全体を管理する。 XenServer/XCP、KVM、QEMU、VMware、Hyper-Vなど、サポートされているハイパーバイザーのいずれか1つを実行
大規模環境の場合は、コンピュートノードを「セル」と呼ばれるグループ単位で分け、DBとメッセージングの負荷を分散することが可能。
1つのセルに対し1つのconductorと、さらにクラウド用に1つのsuperconductorが動作する。
novaのログ(例)
nova-api.log
nova-compute.log
nova-conductor.log
nova-scheduler.log
nova-controller.log
インスタンス起動の流れ
nova-compute以外のすべてのNovaコンポーネントは、DBに直接アクセスする。
nova-computeはDBが必要になると、nova-conductorにアクセスを依頼する。
• APIを介してKeystoneからトークンを取得
• nova-api がインスタンスを起動するよう、CLIなどでアプリケーションはトークンを指定しリクエストを送信
• nova-api はAPIを介してトークンが有効かKeystoneに確認し、有効な場合Keystoneはユーザーのロールを返す
• nova-api はいくつかの予備チェック(ロールとポリシーを使用した権限付与など)を実行
• エラーがなければ、nova-api はnova-conductor に対し、メッセージキュー経由でインスタンス起動リクエストを送信する。nova-api はその後、要求元のアプリケーションに成功した旨を返信する。(インスタンスは未実行)。 残りの作業はバックグラウンドで実行される
• nova-conductor はコンピュートホストが必要になったため、nova-scheduler に1つ選択するよう要求する
• nova-conductor は、選択されたホストのnova-compute に対し、インスタンスの起動準備を要求する
• nova-compute と nova-conductor は協力し、ストレージとネットワークを設定する。これには、Neutron、 Glance、Cinder(インスタンスの起動にボリュームアタッチが必要な場合)へのAPIリクエストが必要。 このフェーズでエラーが発生すると、インスタンスはERROR 状態になる
• ストレージとネットワークの準備が完了すると、nova-compute はハイパーバイザーに対して、仮想マシン の起動を要求し、これが成功するとインスタンスがACTIVEになる
Computeの管理について
リージョン
地理的なデータセンターの分離(Tokyo,Osakaなど)
各リージョンには専用のNova、Glance、Neutron などがあり、それぞれに専用のAPIエンドポイントのセットがあるが、Keystoneデータベースと認証URLは、それぞれ1つのものをすべてのリージョンで共有する。(同じユーザー名、プロジェクト名、ドメイン名、およびパスワードがすべてのリージョンで有効)
セル(スケーリング)
コンピュートサーバーを複数のセット(セル)に分け、それぞれにDBやメッセージキューサーバーを立てて各サーバーの負荷を下げる。
Cell 0
→適切なコンピュートノードが見つからなかったために起動できなかったインスタンスを保持すること
Cell 1(2,3..)
・コンピュートノードと、そこで実行されるnova-compute
・専用のデータベースとメッセージキュー(他のセルと共有はされない)
・セル内で実行中のインスタンスを管理するnova-conductor
各セルには、データベース、メッセージキュー、およびコンダクターを収容する専用のコントローラーがある
アグリゲート(論理的なグルーピング)
コンピュートノードは複数のホストアグリゲートに所属できる
クライアントから直接アグリゲートは表示されない
2種類のネットワーク速度をそれぞれのネットワークに接続するホスト用で2つのアグリゲートを作成
# openstack aggregate create 10g
# openstack aggregate create 1g
# openstack aggregate add host 10g host10
# openstack aggregate add host 1g host1
クライアントがネットワークの帯域幅を選択できるように、管理者は2つのフレーバーを作成
# openstack flavor create large‐10g ‐‐id 10 ‐‐ram 8192 ‐‐disk 80 ‐‐vcpus 4
# openstack flavor create large‐1g ‐‐id 1 ‐‐ram 8192 ‐‐disk 80 ‐‐vcpus 4
フレーバーとアグリゲートを紐づけるため、メタデータを指定。メタデータをアグリゲートに追加
# openstack aggregate set 10g ‐‐property netspeed=10
# openstack aggregate set 1g ‐‐property netspeed=1
その後、フレーバーにメタデータを追加
# openstack flavor set 10 ‐‐property aggregate_instance_extra_specs:netspeed=10
# openstack flavor set 1 ‐‐property aggregate_instance_extra_specs:netspeed=1
ユーザーは、フレーバー10 を指定することで、10G のネットワーク速度を選択できる
# openstack server create ‐‐image ... ‐‐flavor 10 ‐‐network ... fastinstance
スケジューラーはAggregateInstanceExtraSpecsフィルターを使用して適切なホストを選択するため、フレーバーのプロパティにはaggregate_instance_extra_specs のプレフィックスが含まれている必要がある。
アベイラビリティゾーン(物理的なグルーピング)
コンピュートノードは1つのアベイラビリティゾーンにのみ所属可能
アベイラビリティゾーンはユーザーから直接確認可能
ホストアグリゲートを作成後、アベイラビリティゾーンaz1 と az2 としてクライアントに公開
# openstack aggregate create building1 ‐‐zone az1
# openstack aggregate create building2 ‐‐zone az2
# openstack aggregate add host building1 host1
ユーザーは、以下のように特定のアベイラビリティゾーンでインスタンスを起動できる
# openstack server create ‐‐image ... ‐‐availability‐zone az1 instance1
# openstack server create ‐‐image ... ‐‐availability‐zone az2 instance2
Glance
• 利用可能なイメージの一覧表示
• イメージの保存
• インスタンススナップショットの保存(インスタンスの迅速なバックアップのための解決策)
imageのアップロード
Glance は、イメージの定義(メタデータを含むプロパティ)をカタログに保持し、イメージデータ(イメージファイルの中身)は、Glanceストア(バックエンド)に保存される。ストアにはいくつかの種類が存在する。
・Swift: (イメージ データは Swift オブジェクトに格納される)
・Ceph: (イメージデータはCeph オブジェクトに格納される。最も広く使用されている)
・Cinder: (イメージデータはCinder ボリュームに格納される)
・File: (イメージデータは通常のファイルに格納される)
など...
イメージは以下のステップで Glance に追加される。
①カタログエントリが作成され、イメージの一覧やそのプロパティを表示できるようになる。この時点でのステータスは "queued" であり、データはまだアップロードされていないためダウンロードはできない。
②Glance で設定されたストアの1つにイメージデータが追加される。この時点でイメージ のステータスは "active" に変わり、イメージを使用してインスタンスをプロビジョニングできるようになる。
※イメージデータの保存には、いくつかの方法がある。通常はファイルをストアにコピーするが、URLから直接イメージをコピーすることもできる。また特定の種類のイメージストア(Ceph や Cinder など)では、何もアップロードせずに、既存のイメージデータへのポインタをイメージのカタログエントリに追加することも可能
※ストアが複数ある場合、一般ユーザーがイメージを作成すると、Glance はその構成に基づいてストアを選択する。管理者の場合は、イメージを作成するときにイメージストアを選択できる。
Neutron
一般的にpublic は、データセンター内の物理ネットワークあるいはVLANを表す、いわゆるプロバイダーネットワークのこと。クラウドのテナントネットワークと外部を接続する、外部ネットワークでもある。
private は、仮想ネットワークでありテナントネットワークともいわれる。
Network Agent
実装されているNeutron管理のコンポーネント。以下はコンポーネントの例
（※実装により内容は異なる）
# openstack network agent list
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
| 26e8b83a-2165-4493-9f6d-9295efbdddae | Metadata agent | host01 | None | :-) | UP | neutron-metadata-agent |
| 2f55ee83-e018-4316-945a-a218b41e466a | Open vSwitch agent | host01 | None | XXX | UP | neutron-openvswitch-agent |
| 35dc0210-4f8c-40ab-8114-0e92548bcb4c | L3 agent | host01 | nova | :-) | UP | neutron-l3-agent |
| a5abaa90-024a-47df-b047-39fcad4e8d78 | DHCP agent | host01 | nova | XXX | UP | neutron-dhcp-agent |
+--------------------------------------+--------------------+----------+-------------------+-------+-------+---------------------------+
L3 エージェント
通常はコントローラーに実装される。デフォルトのL3プラグインは、Linuxカーネルのnetfilterモジュール (iptablesコマンドとしても知られる)を使用し、以下を実行する。
• テナントネットワーク間のルーティング
• テナントネットワークから外部へのルーティング(SNAT)
• フローティング IP と対応する静的 IP のマッピング(DNAT)
分散ルーターを実装するL3エージェントも、コンピュートノードで実行される。 ネットワークのIPアドレス範囲は重複可能なため、ルーターはネットワーク名前空間を使用して分離を実現する。
DHCP エージェント
デフォルトのDHCPエージェントはdnsmasqを使用し、NeutronネットワークにDHCPサーバーを実装する。DHCPプロトコルはデフォルトでHAをサポートしているため、特別な設定を行わなくても複数のコンピュートノードにDHCP エージェントを展開できる。
L2 エージェント
インスタンスの起動時に、コントローラーとコンピュートノードに必要なネットワークリソースを設定する。 どのリソースかは、仮想ネットワークの実装に使用されるテクノロジーによって決まる(ここではOpen vSwitch agent)
メタデータエージェント
インスタンスがのNovaメタデータAPIにアクセスすると、メタデータエージェントはNovaにトラフィックを転送する
メータリングエージェント
L3トラフィックの統計情報を、メータリングサービスであるCeilometerに送信する
コンピュートのNW構成例
OpenStackコンピュートノード上のNW構成
物理IF(ensXXやethXXなど)を２つで組まれたbond2のIFにVLAN設定をしている
[root@compute01 ~]# ifconfig -a
bond2: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet6 fe80::6a05:caff:feee:4d80 prefixlen 64 scopeid 0x20<link>
ether 68:05:ca:ee:4d:80 txqueuelen 1000 (Ethernet)
RX packets 34269734284 bytes 13748066852179 (12.5 TiB)
RX errors 0 dropped 17184 overruns 13338128 frame 0
TX packets 13730403295 bytes 3221634520635 (2.9 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
bond2.2000: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 68:05:ca:ee:4d:80 txqueuelen 1000 (Ethernet)
RX packets 8632946400 bytes 9910185661038 (9.0 TiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8256999611 bytes 903870784569 (841.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
brq5a0f4f22-25: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::bc68:f0ff:fe5e:8aec prefixlen 64 scopeid 0x20<link>
ether 68:05:ca:ee:4d:80 txqueuelen 1000 (Ethernet)
RX packets 337851689 bytes 18532250036 (17.2 GiB)
RX errors 0 dropped 26 overruns 0 frame 0
TX packets 5 bytes 446 (446.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap2120a356-13: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::fc16:3eff:fe55:46e9 prefixlen 64 scopeid 0x20<link>
ether fe:16:3e:55:46:e9 txqueuelen 1000 (Ethernet)
RX packets 6551904 bytes 1217679154 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 299519500 bytes 21209106360 (19.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapd85f9531-b9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::fc16:3eff:fe13:c098 prefixlen 64 scopeid 0x20<link>
ether fe:16:3e:13:c0:98 txqueuelen 1000 (Ethernet)
RX packets 1818452131 bytes 193211029716 (179.9 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1949415535 bytes 2299854711533 (2.0 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:28:e5:d7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr0-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 52:54:00:28:e5:d7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@compute01 ~]# brctl show
bridge name bridge id STP enabled interfaces
brq5a0f4f22-25 8000.6805caee4d80 no bond2.2000
tap2120a356-13
tapd85f9531-b9
virbr0 8000.52540028e5d7 yes virbr0-nic
[root@compute01 ~]#
[root@compute01 ~]# virsh net-list
名前 状態 自動起動 永続
----------------------------------------------------------
default 動作中 はい (yes) はい (yes)
[root@compute01 ~]#
### virbr0 につながっているlibvirtによる自動NAT設定付きネットワーク。brq...などのブリッジはneutronの管理なので出力されない
controller側の設定
[root@controller ~]$ openstack network show 5a0f4f22-2359-4ba0-b246-d56533594cc4
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2021-08-02T23:24:10 |
| description | |
| id | 5a0f4f22-2359-4ba0-b246-d56533594cc4 |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| mtu | 1500 |
| name | test-nw1 |
| port_security_enabled | False |
| project_id | 677e542f17314bf6ab9533e7b15401f8 |
| provider:network_type | vlan |
| provider:physical_network | datacentre |
| provider:segmentation_id | 2000 |
| router_external | Internal |
| shared | True |
| status | ACTIVE |
| subnets | e14b6f53-7b93-4c3a-be90-60195d4fe5e1 |
| tags | [] |
| updated_at | 2022-02-14T08:49:50 |
+---------------------------+--------------------------------------+
[root@controller ~]$
[root@controller ~]$ openstack subnet show e14b6f53-7b93-4c3a-be90-60195d4fe3f1
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| allocation_pools | 172.21.110.1-172.21.110.254 |
| cidr | 172.21.110.0/24 |
| created_at | 2021-08-02T23:25:17 |
| description | |
| dns_nameservers | |
| enable_dhcp | False |
| gateway_ip | None |
| host_routes | |
| id | e14b6f53-7b93-4c3a-be90-60195d4fe5e1 |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | test-nw1-subnet |
| network_id | 5a0f4f22-2359-4ba0-b246-d56533874bd4 |
| project_id | 677e542f17314bf6ab9533e7b15401f8 |
| subnetpool_id | None |
| updated_at | 2022-02-14T08:32:38 |
+-------------------+--------------------------------------+
[root@controller ~]$
通信フロートしては以下となる。
[VMインスタンス] ※portがアタッチされ、サブネット内のIPが付与されている
│
[tapインターフェース] ※VMにNICがアタッチされるたびに作成される。
│
[brq5a0f4f22-25] ← Neutronの仮想ブリッジ
│
[bond2.2000] ← VLAN 2000がタグ付与される物理IF
│
[対向NWスイッチ] ← VLAN 2000 タグを認識する必要あり
NAT
仮想router
インスタンス→外部NWへ通信したい場合
PrivateNWとPublicNWを紐づけられる。
# openstack router create test-router1
→ test-router1 という仮想ルーターを作成
（最初はどのサブネットにも繋がっていない、単体のルーター）
# openstack router add subnet test-router1 common-subnet2
→ common-subnet2（例：192.168.10.0/24など）という L3NWと仮想ルーターを接続
→ このサブネット内のVMが test-router1 をデフォルトゲートウェイとして使えるようになる
[External Network (provider)]
▲
│（ゲートウェイに設定）
┌──────┴───────┐
│ test-router1 │ ← 仮想ルーター（L3）
└────┬─────────┘
│
┌──────┴──────┐
│ subnet-a (192.168.10.0/24)
│ subnet-b (192.168.20.0/24)
FloatingIPとの併用で外部から直接VMへ接続させることも可能
FloatingIP
外部NW→インスタンスへDNATで通信したい場合
FloatingIPへのトラフィックの宛先アドレスは、FloatingIPが設定されているインスタンスのアドレスに上書きされる
[外部ネットワーク]
│
Floating IP（203.0.113.10）
│ DNAT
┌─────▼──────┐
│ 仮想ルーター │ ← SNATもここで処理
└─────▲──────┘
│
[tenant network]
│
[VM: 192.168.100.10]
Cinder/Swift
Storageの概要
エフェメラルストレージ
使用目的：OSのルートディスクとスクラッチ領域
使用例：/dev/vda(10GBのOSルート領域),/dev/vdb(5GBの一時領域)
ライフサイクル：インスタンスが存在する限り
データへのアクセス：インスタンス
実装：最も一般的なのは、コンピュートノードのFS上のファイル
サイジング：Novaフレーバーから
Cinder Block ストレージ
使用目的：インスタンス用の永続ボリューム(Blockデバイス提供)
使用例：1TBボリュームとデータベース、ボリュームからインスタンス起動
ライフサイクル：削除されるまで保持(インスタンスからデタッチ→別のインスタンスに再アタッチ可)
データへのアクセス：インスタンス
実装：LVM,Array,NFSなど
サイジング：作成時のパラメータから
Swift Object ストレージ
使用目的：バイナリオブジェクトの保管
使用例：アーカイブ、バックアップ、メディアストレージ
ライフサイクル：削除されるまで保持
データへのアクセス：URL経由でアクセス(RESTAPI)
実装：通常は汎用ハードウェアに実装
サイジング：オブジェクトのサイズから
Cinder
Cinder コンポーネントをすべて一覧表示
openstack volume service list
Cinderアーキテクチャ
Novaと似ており、Cinderは内部通信にメッセージキューを使用してステータスをSQLデータベースに格納する。
cinder-apiはAPIリクエストを受け取り、適切なCinderコンポーネントに転送する。WSGIプロトコルを介し、ボリュームのAPIリクエストを転送するWebサーバー内で実行される。
cinder-volumeは、ボリュームドライバーを介して物理ブロックストレージデバイスと通信して管理を行う。 Cinderプロジェクトには、ブロックストレージを実装するLVMとNFSの2つのリファレンスドライバーがあるが、他のストレージソリューションベンダーや、Cephなどのオープンソースストレージプロジェクト等は独自のドライバーを提供している。
これらのドライバー、ドライバーのパラメーター、および物理ストレージデバイスの組み合わせを、バックエンドと呼ぶ。構成されたバックエンドごとに1つのcinder-volumeプロセスが実行される。
cinder-schedulerは、新しいボリュームが作成されると、そのボリュームが存在するべき場所(バックエンド)を決める。※容量、アベイラビリティゾーン、ボリュームタイプなどの属性でフィルタリングできる。
cinder-backup は、ボリュームのバックアップ、リストアなどを管理する
アタッチの流れ
・LVM/iSCSI ドライバーが使用されており、NovaがKVMを使用しているケース
1. Cinder ボリュームはLVM ボリュームとして表され、ボリュームグループは cinder.conf で設定される。 Cinder ボリュームが作成されると、対応する論理ボリュームがストレージノード上に作成される。
2. インスタンスにボリュームをアタッチする際、Nova は Cinder に対し、ボリュームを available にするよう要求する。
3. LVM/iSCSI ドライバーはiSCSI 経由でボリュームをavailable にする。ストレージノードでは、ボリュームの iSCSI ターゲットが作成される。
4. インスタンスが実行されるコンピュートノードではiscsiadmコマンドが使用され、iSCSI ターゲットとボリュームがインポートされる。
5. Nova は libvirt を使用し、インスタンスにボリュームをアタッチする。
スナップショットとバックアップ
・インスタンスのスナップショット(別名バックアップイメージ)は、Glance にアップロードされたルートディスクのコピー
・ボリュームのスナップショットは、ボリュームのある時点での読み取り専用コピーのことを指す。
・ボリュームのバックアップは、Cinderの外部に置くボリュームコピーのこと。2025時点でサポートされているバックアップサービスは、Swift (デフォルト)、Ceph、IBM Tivoli Storage Manager、NFS、Google Drive、GlusterFS、およびファイルシステムで、使用できるバックアップサービスは1つのみ(cinder.confで設定)
Swift
Swiftは、オブジェクトをコンテナーに入れ込む。オブジェクトごとに5GBのサイズ制限があるが、大きなオブジェクトを小さなチャンクに分割し、アップロードすることも可能。オブジェクトを格納するには、アカウントに少なくとも1つのコンテナーが必要。
・オブジェクトは、そのURLを使用してアップロードやダウンロードができる。オブジェクトデータとともに、メタデータもキーバリューペア(キーと値のペア)の形式で格納されるが、ユーザーはオブジェクトに任意のメタデータを追加できる。
・オブジェクトバージョニングをサポートしており、コンテナーにもカスタマイズしたメタデータや、特定の意味のメタデータ(バージョニングなど)を設定できる。
・オブジェクトのアクセス制御をコンテナーに定義できる。コンテナーには、どのアカウントに読み取りおよび書き込みアクセス権があるかを決定するACLを設定できる。(SwiftはコンテナーACLのみで、オブジェクトにはACLを設定できない)
・アカウントは、OpenStackでいうところの”プロジェクト”に相当する。任意の数のコンテナーを持つことができ、コンテナーと同様、メタデータ(コンテナーのリストやサイズなど)を保持する。
アカウント>コンテナー>オブジェクトの階層は、オブジェクトのURLを形成するために使用される。
たとえば、Swiftクラスターには obj.example.com によってアクセスし、アカウント名がAccount343、コンテナー名がPhotos、オブジェクトが Cats/kitten.jpg であった場合、URL は https://obj.example.com/v1/Account343/Photos/Cats/kitten.jpg になる。("v1"は、SwiftのAPIバージョン)
Swiftアーキテクチャ
swift クラスターのノードは、アクセス層とストレージ層に分けることができる。
アクセス層のノード
swift-proxy-server プロセスを実行し、通常はその手前にロードバランサーがある。
プロキシサーバーの主なタスクは、リクエストを受信し、適切なストレージノードに転送すること。
ストレージノードを判別するには、コンテナー名またはオブジェクト名を、サーバーとディスクの場所に変換する。
これは、リングというデータ構造を使用して行われる。リングはファイルに存在し、そのファイルはクラスター内のすべてのノードに複製される。(このファイルには名前とディスクのマッピング情報が含まれる)
プロキシサーバーは一部の障害についても処理する(オブジェクトノードが応答しない場合など)が、オブジェクトやコンテナーがキャッシュされるわけではないため、データが破損した場合は修復されない。
ストレージノード
実際のアカウント、コンテナー、およびオブジェクトデータを持ち、アカウント、コンテナー、およびオブジェクトサーバープロセスを実行する。多くの場合、ストレージノードは以下3種類のデータをすべて持ち、3種類のプロセスを実行する。
• オブジェクトサーバーは、ストレージノード上の実際のオブジェクト(ファイル)を管理する。 ストレージデバイス上のオブジェクトの格納、取得、および削除を担う。 各オブジェクトのレプリカは、ファイルシステム上の1つのファイルに保存され、オブジェクトのメタデータは、そのファイルの拡張属性に格納される。これには、拡張属性をサポートするファイルシステム(XFSなど)が必要。メタデータには etagという、オブジェクトのコンテンツに基づいたハッシュ値が含まれる。
• コンテナーサーバーは、コンテナー内のオブジェクトのリストと統計情報(サイズなど)を管理する。 コンテナーのデータはSQLiteデータベースファイルに格納される(これも複製される)。コンテナーサーバーは、オブジェクトが物理的にどこに格納されているのかは知らず、管理するコンテナーに属するオブジェクトのみを認識する。
• アカウントサーバーは、コンテナーのリストと統計情報を管理する(コンテナーサーバーがオブジェクトのリストと統計情報を管理するのと同様)。
上記のサーバープロセスに加え、以下のハウスキーピングプロセスが、すべてのストレージノードで実行される。
auditorプロセス：オブジェクトのコンテンツとetagを比較することで、データの消失や破損を検出する。
replicatorプロセス：必要に応じてレプリカを再作成する。
updaterプロセス：サマリー統計情報の一貫性を確保する
reaperプロセス：削除用にマーキングされたアカウントをバックグラウンドで処理する
Telemetry
OpenStackクラウドのインフラストラクチャに関する測定データを生成、処理、および保存する。
主な使用例:
• 顧客への課金に必要な測定値を、クラウドプロバイダーに提供
• OpenStack のオーケストレーションサービスであるHeatと協力し、アプリケーションのスケーリングの決定に必要なデータとアラーム処理を提供
• 監視ツール、デバッグ、およびキャパシティプランニングに必要なデータを提供
サンプリング: Ceilometer は、クラウドから測定データとイベントデータをポーリングし、ストレージやその他の サービスに公開する
測定値の保存: Ceilometer の測定値ストレージソリューションとして、時系列データの汎用データベースであるGnocchi という別のサービスに測定データが保存される。(Rockyのデフォルト)
イベントストレージ: Ceilometer は、数値以外のイベントも生成する。
アラーム処理: Liberty 以降、Aodhと呼ばれる。Ceilometer は、Gnocchi およびPanko API を使用し、測定データとイベントデータを保存する。同様に、Aodh は Gnocchi とPanko それぞれのAPI を介して、データを取得する。
Ceilometer
Ceilometer がサンプルを取得する方法について
通知
さまざまなOpenStack サービスが、独自のTelemetryデータを Ceilometer に送信する。
サービスはメッセージキューインフラストラクチャを使用し、Ceilometer の通知エージェントにサンプルを送信する。
ポーリング
Ceilometer が通知から受け取るデータに加え、いくつかの方法を使ってデータを追加で収集する。
Ceilometer には、以下の方法が組み込まれています。
• 他のサービスへのAPI リクエスト。これはCeilometer の中央エージェントのタスク
• クラウドで使用されるハイパーバイザーへのポーリング。Ceilometer のコンピュートエージェントはコンピュートノードで実行され、Nova を経由せずにハイパーバイザーに直接接続する。
• 個々のコンピュートノードから、IPMI センサーデータおよびIntel Node Manager データを収集する。このタスクはIPMIエージェントが担っている。
エージェントによって収集されたデータは通知エージェントにも送信され、そこで処理および公開される。
Dynamic Pollsters ポーリングは、エージェントフレームワーク、および pollster というPythonプラグインによって実装されている。
アラーム
Aodh というアラームサービスで、ルールとアクションによって定義される。
ルールは、アラームの状態(state)を決定するブール式で、ルールの評価が真の場合、状態は alarm 、評価が偽の場合、状態は ok になる。また、アラームのルールを評価するのに充分なデータが無い場合、状態はinsufficient data になる。
アラームの状態が変化するとアクションがトリガーされる。設定可能なアクションには、定義されたURLへのHTTP POST、ログファイルへの書き込み、あるいはZaqarメッセージキューへの書き込み等がある。
Heat
OpenStack のオーケストレーションサービス
Heatテンプレートには、クラウドアプリケーションのインフラストラクチャが定義されている。2つのテンプレート形式がサポートされている。
• Heat Orchestration Template(HOT):YAML に基づいている。
• Amazon Cloud Formation(CFN):JSON に基づいている。
テンプレートはテキストファイルであるため、Git リポジトリなどのコードと同じように管理できる。
Heatアーキテクチャ
heat-api
OpenStack ネイティブのREST API を提供する。このREST API は、APIリクエストを heat-engine に送信する。
heat-api-cfn
AWS CloudFormation API を提供し、API リクエストをheat-engine に送信する。オートスケールのアラームを実装する上で重要な要素であり、アラームの条件が真になると、アラームのアクションとしてCloudFormation URL にPOST リクエストが送信される。
heat-engine
テンプレートの起動のオーケストレーションを行い、イベントをAPI コンシューマーに返す。これはテンプレート主導で行われる。
(おまけ)コマンド集
※現在ではnovaやneutronなどの固有のクライアント用コマンドではなく、
openstackコマンドの使用が推奨らしいので記載していません。
### Openstackのサービス、エンドポイント、サービスカタログ一覧
openstack service list
openstack endpoint list
openstack catalog list #サービスカタログは、OpenStackの認証サービス（Keystone）が提供するもの.サービス名のほか、public(外部からのアクセス用),internal(内部通信（サービス間通信）用)admin(管理者向け)などのエンドポイントも表示される
### ドメイン作成・確認
# ドメインはプロジェクトを内包する階層の最上位
openstack domain create TESTDOMAIN
openstack domain list
openstack domain show TESTDOMAIN
### プロジェクト作成・確認
# 各プロジェクトは特定のドメインに関連付けられる。プロジェクトが存在するドメインのポリシーや設定がプロジェクトにも適用される。
openstack project create --domain default --description "TEST" testproject
openstack project list
### ユーザー作成・確認
openstack user create --domain default --project testproject --password userpassword openstackuser
openstack user list
### ロール作成・割当て・確認
# ロールは、ユーザーまたはサービスアカウントに割り当てることのできる権限のセットを定義する。例えば、「admin」、「member」、「reader」などのロールがある。
openstack role create admin
# roleは一応作成できるが、nameくらいしか変えられない。実際の権限はpolicyで定義されているがハードコーディングされている。
openstack role list
openstack role add --project testproject --user openstackuser admin #testprojectのopenstackuserユーザにadminロール付与
openstack role assignment list --user openstackuser --project testproject
### imageカタログエントリの作成&アップロード/確認 (imageを落としてきて登録する場合)
openstack image create "cirros" --file cirros-0.6.2-x86_64-disk.img --disk-format qcow2 --container-format bare --public --debug --progress
openstack image list
### フレーバーの作成・制限などの編集・確認
openstack flavor create --id 11 --vcpus 1 --ram 2048 --disk 30 --swap 2048 sa.tiny
openstack flavor list
openstack flavor show FLAVORNAME
# flavorに対して制限をかける場合
openstack flavor set --property quota:disk_total_iops_sec=625 --property quota:vif_inbound_average=125000 --property quota:vif_outbound_average=125000 sa.large
### ノードリスト・詳細確認
openstack host list
openstack host show NAME
openstack hypervisor list
openstack hypervisor show NAME
openstack network agent list # コンピュートノードで起動しているエージェントの一覧。"Metadata agent"やOVSの場合は"Open vSwitch agent"などが動いている
### セキュリティグループ設定・確認
# いわゆるファイアウォールのプロファイル。デフォルトではすべての受信トラフィックを無効、送信トラフィックについては制限なし
openstack security group create secgrp01
openstack security group rule create --protocol icmp --ingress secgrp01
openstack security group rule create --protocol tcp --dst-port 22:22 secgrp01
openstack security group rule list secgrp01
### キーペア設定
# 既存のSSHパブリックキーを使用してOpenStackにキーペアを作成し、インスタンスへSSHアクセス
openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey
### ネットワーク確認・作成
openstack network create --provider-physical-network datacentre --provider-network-type flat --external common-nw-2 #typeはflat(単一NW),vlan,vxlan,gre/geneveなど.--provider-physical-networkオプションはflat,vlanの場合のみ必須
openstack network create --provider-physical-network datacentre --provider-network-type vlan --external --share --provider-segment 111 external-111 #VLAN111を付与する場合
openstack network list
openstack network show NWNAME
### サブネット確認・作成
openstack subnet create common-subnet2 --network common-nw2 --subnet-range 172.24.0.0/24 --allocation-pool start=172.24.0.20,end=172.24.0.99 --gateway 172.24.0.254 --dns-nameserver 8.8.8.8 --no-dhcp
openstack subnet list
openstack subnet show SUBNETNAME
### router設定 (ルータをサブネット上に作成し、外部に接続できるNWと紐づける)
openstack router create test-router1
openstack router add subnet test-router1 common-subnet2 #common-subnet2 に対するルーティングを提供
openstack router set test-router1 --external-gateway external-111 #NW "external-111" をゲートウェイとして設定
### port作成 (特定のIPアドレスを持つポートを事前に作成し、VMに割り当てられる)
openstack port create --network common-nw2 --fixed-ip subnet=common-subnet2,ip-address=172.24.0.23 fixedip3-eth1
#port情報更新
openstack port set --fixed-ip subnet=SUBNETNAME,ip-address=X.X.X.X PORTNAME
### 仮想マシン(インスタンス)作成・リスト・詳細確認
openstack server create --flavor m1.small --image cirros --security-group secgrp01 --network common-nw2 --key-name mykey --debug --wait sv01 --availability-zone nova::node01.local
--user-data data.yaml
でcloud-initやスクリプトで設定を仕込むこともできる
openstack server list --all-projects
openstack server show INSTANCEID
openstack server list --long -c Name -c Host -c ID #カラムを選択して表示
### floatingIP設定
# 外部からSSHでインスタンスにアクセスする場合や、ウェブサーバーへHTTPリクエストを受ける場合に必要
openstack floating ip create public-net #public-netというNWから利用可能なフローティングIPを生成
openstack floating ip list
openstack server add floating ip sv01 <floating ip> #インスタンスへ設定することで、外部NWからDNAT(FloatingIP→PrivateIP)してアクセスできるようになる
### VMコンソール
openstack console url show VMNAMEorID
#表示されるURLでアクセスできる
### インスタンスのスナップショット
openstack server image create VMNAME --name SNAPSHOTNAME #ルートディスクのコピーを作成し、Glanceイメージカタログに追加。同じ名前を持つ既存のイメージは上書きされる。
openstack server backup create VMNAME --name SNAPSHOTNAME --rotate 3 #ルートディスクのコピーをGlanceにアップロード。同じ名前のイメージは名前が変更される。‐‐rotateオプションによって、既存イメージをいくつ残すか指定できる。
#スナップショットは、インスタンスが停止しているときだけではなく、休止、一時停止、あるいは実行中にも作成できるが、ファイルシステム構造の一貫性が保たれない可能性がある。
### Cinderボリューム作成
openstack volume create myvol1 --size 1 #--image でglanceイメージをソースとして指定すれば自動的にブート可能になる。sizeパラメーター(GB)必要。削除はdelete
openstack volume list #STATUSはavailable,VMへアタッチされるとin-useに変わる
### ボリュームのアタッチ
openstack server add volume myvm myvol1 #デタッチはremove
### ボリュームのスナップショット/スナップショットからボリューム新規作成
openstack volume snapshot create --volume VOLUMEID --name mybootvol --force #アタッチされているボリュームから取るには--forceが必要
openstack volume create --snapshot mybootvol backintime
### ボリュームのバックアップ/リストア
openstack volume backup create VOLUME
openstack volume backup restore BACKUP
cinder --os-volume-api-version 3.47 create --backup-id BACKUPID
### Swiftコンテナー作成
openstack container create photos
openstack container list
### Swiftオブジェクト作成(アップロード)
openstack object create photos kitten.jpg #saveでダウンロード
openstack object list photos
swift stat photos kitten.jpg -v #表示されるURLからダウンロードやcurlアクセスができる
swift post photos --read-acl .r:*,.rlistings #コンテナー内のオブジェクトを誰とでも(Swift アカウントを持たないユーザーも含む)共有するACL設定
### ライブマイグレーション
# 移行可能なノード一覧を取得する
openstack compute service list
# 特定のノードの詳細を表示する
openstack host show NODENAME
# インスタンス INSTANCEID をホスト HOSTNAME へブロックライブマイグレーションする場合：
openstack server migrate --live HOSTNAME --block-migration INSTANCEID #共有ストレージが使用可能な場合、--block-migration オプションを省略することで通常のライブマイグレーションを行う
### 環境変数設定(テナントごとの認証情報を読み込む)
export OS_PROJECT_DOMAIN_NAME=default
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_NAME=test-project
export OS_USERNAME=openstackuser
export OS_PASSWORD=password
export OS_AUTH_URL=http://openstackhost02:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2
#source,. コマンドで読み込む
ポート作成〜VMへのアタッチ
portのVMへのアタッチ手順の流れ。確認verはmitaka(古いので注意！)
もととなるネットワーク、サブネットは既に作成されている前提
[root@host01 ~]# openstack network list |grep test
| 80cea015-9432-43b5-957e-b0a355362ca3 | test-nw1 | 88c103e3-a347-44bc-99ce-92960a705ac7 |
| e57d9ccb-beef-43dd-a2cb-e3d27c25baac | test-nw2 | 72ff1e97-3665-4d97-b612-20935aad27d1 |
[root@host01 ~]#
[root@host01 ~]# openstack subnet list |grep test
| 88c103e3-a347-44bc-99ce-92960a705ac7 | test-nw1-ipv4 | 80cea015-9432-43b5-957e-b0a355362ca3 | 100.60.0.0/24 |
| 72ff1e97-3665-4d97-b612-20935aad27d1 | test-nw2-ipv4 | e57d9ccb-beef-43dd-a2cb-e3d27c25baac | 100.80.0.0/24 |
[root@host01 ~]#
[root@host01 ~]# neutron port-list |grep test
| 013e78f2-8b81-4990-bdb3-9348a4a65079 | testvm01-eth0 | fa:16:3e:42:0b:00 | {"subnet_id": "6a0ec31a-be64-465c-9d4a-6858bd407a4f", "ip_address": "172.21.0.123"} |
| 33badf00-e213-4e75-8859-0a786c95e207 | testvm01-eth1 | fa:16:3e:10:b4:f9 | {"subnet_id": "94a6e471-d7a7-46e7-8049-dce6b4380e2e", "ip_address": "10.10.0.73"} |
| 56ddf9a4-6ce9-4e1b-8a23-abaaa9e911e6 | testvm01-eth2 | fa:16:3e:e6:93:d8 | {"subnet_id": "0d63c156-e402-4365-841c-92ddbd3a4a8e", "ip_address": "192.168.10.144"} |
| a7db9fb2-bd40-4c87-bd30-4107ecc6099c | testvm01-eth3 | fa:16:3e:b0:72:9c | {"subnet_id": "88c103e3-a347-44bc-99ce-92960a705ac7", "ip_address": "100.60.0.22"} |
[root@host01 ~]#
[root@host01 ~]#
[root@host01 ~]# neutron port-create \
> --name testvm01-eth4 \
> --fixed-ip subnet_id=test-nw2-ipv4,ip_address=100.80.0.35 \
> --port-security-enabled=false \
> test-nw2
Created a new port:
+-----------------------+----------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+----------------------------------------------------------------------------------+
| admin_state_up | True |
| binding:host_id | |
| binding:profile | {} |
| binding:vif_details | {} |
| binding:vif_type | unbound |
| binding:vnic_type | normal |
| created_at | 2022-01-21T05:22:59 |
| description | |
| device_id | |
| device_owner | |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "72ff1e97-3665-4d97-b612-20935aad27d1", "ip_address": |
| | "100.80.0.35"} |
| id | d44d2f3e-e97c-45aa-a670-ea99928478ee |
| mac_address | fa:16:3e:55:23:27 |
| name | testvm01-eth4 |
| network_id | e57d9ccb-beef-43dd-a2cb-e3d27c25baac |
| port_security_enabled | False |
| status | DOWN |
| tenant_id | 137e88f78dc84d3f964dd0af9f5f7a60 |
| updated_at | 2022-01-21T05:22:59 |
+-----------------------+----------------------------------------------------------------------------------+
[root@host01 ~]#
[root@host01 ~]#
[root@host01 ~]# neutron port-list |grep testvm01
| 013e78f2-8b81-4990-bdb3-9348a4a65079 | testvm01-eth0 | fa:16:3e:42:0b:00 | {"subnet_id": "6a0ec31a-be64-465c-9d4a-6858bd407a4f", "ip_address": "172.21.0.123"} |
| 33badf00-e213-4e75-8859-0a786c95e207 | testvm01-eth1 | fa:16:3e:10:b4:f9 | {"subnet_id": "94a6e471-d7a7-46e7-8049-dce6b4380e2e", "ip_address": "10.10.0.73"} |
| 56ddf9a4-6ce9-4e1b-8a23-abaaa9e911e6 | testvm01-eth2 | fa:16:3e:e6:93:d8 | {"subnet_id": "0d63c156-e402-4365-841c-92ddbd3a4a8e", "ip_address": "192.168.10.144"} |
| a7db9fb2-bd40-4c87-bd30-4107ecc6099c | testvm01-eth3 | fa:16:3e:b0:72:9c | {"subnet_id": "88c103e3-a347-44bc-99ce-92960a705ac7", "ip_address": "100.60.0.22"} |
| d44d2f3e-e97c-45aa-a670-ea99928478ee | testvm01-eth4 | fa:16:3e:55:23:27 | {"subnet_id": "72ff1e97-3665-4d97-b612-20935aad27d1", "ip_address": "100.80.0.35"} |
[root@host01 ~]#
[root@host01 ~]# nova interface-list testvm01
+------------+--------------------------------------+--------------------------------------+----------------+-------------------+
| Port State | Port ID | Net ID | IP addresses | MAC Addr |
+------------+--------------------------------------+--------------------------------------+----------------+-------------------+
| ACTIVE | 013e78f2-8b81-4990-bdb3-9348a4a65079 | a3f2bed1-3ace-4b63-b2dc-ee8013693c20 | 172.21.0.123 | fa:16:3e:42:0b:00 |
| ACTIVE | 33badf00-e213-4e75-8859-0a786c95e207 | 28d03a78-6096-4c7f-a5de-32d236aa36f2 | 10.10.0.73 | fa:16:3e:10:b4:f9 |
| ACTIVE | 56ddf9a4-6ce9-4e1b-8a23-abaaa9e911e6 | c82571da-0cb0-4b56-82a1-48de552d1afe | 192.168.10.144 | fa:16:3e:e6:93:d8 |
| ACTIVE | a7db9fb2-bd40-4c87-bd30-4107ecc6099c | 80cea015-9432-43b5-957e-b0a355362ca3 | 100.60.0.22 | fa:16:3e:b0:72:9c |
+------------+--------------------------------------+--------------------------------------+----------------+-------------------+
[root@host01 ~]#
[root@host01 ~]# nova interface-attach --port-id d44d2f3e-e97c-45aa-a670-ea99928478ee testvm01
[root@host01 ~]#
[root@host01 ~]# nova interface-list testvm01
+------------+--------------------------------------+--------------------------------------+----------------+-------------------+
| Port State | Port ID | Net ID | IP addresses | MAC Addr |
+------------+--------------------------------------+--------------------------------------+----------------+-------------------+
| ACTIVE | 013e78f2-8b81-4990-bdb3-9348a4a65079 | a3f2bed1-3ace-4b63-b2dc-ee8013693c20 | 172.21.0.123 | fa:16:3e:42:0b:00 |
| ACTIVE | 33badf00-e213-4e75-8859-0a786c95e207 | 28d03a78-6096-4c7f-a5de-32d236aa36f2 | 10.10.0.73 | fa:16:3e:10:b4:f9 |
| ACTIVE | 56ddf9a4-6ce9-4e1b-8a23-abaaa9e911e6 | c82571da-0cb0-4b56-82a1-48de552d1afe | 192.168.10.144 | fa:16:3e:e6:93:d8 |
| ACTIVE | a7db9fb2-bd40-4c87-bd30-4107ecc6099c | 80cea015-9432-43b5-957e-b0a355362ca3 | 100.60.0.22 | fa:16:3e:b0:72:9c |
| ACTIVE | d44d2f3e-e97c-45aa-a670-ea99928478ee | e57d9ccb-beef-43dd-a2cb-e3d27c25baac | 100.80.0.35 | fa:16:3e:55:23:27 |
+------------+--------------------------------------+--------------------------------------+----------------+-------------------+
[root@host01 ~]#
[root@host01 ~]# nova list |grep testvm01
| 09a55ec1-bb1e-42ba-bb68-015c9038cf72 | testvm01 | ACTIVE | - | Running | kensho-nw1=10.10.0.73; kensho-nw2=172.21.0.123; kensho-nw3=192.168.10.144; test-nw2=100.80.0.35; test-nw1=100.60.0.22 |
[root@host01 ~]#
[root@host01 ~]# openstack server show testvm01
+--------------------------------------+-------------------------------------------------------------------+
| Field | Value |
+--------------------------------------+-------------------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | az01 |
| OS-EXT-SRV-ATTR:host | dev-host02 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | dev-host02 |
| OS-EXT-SRV-ATTR:instance_name | instance-00001c65 |
| OS-EXT-STS:power_state | 1 |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2019-08-27T05:00:56.000000 |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | kensho-nw1=172.21.0.123; |
| | kensho-nw2=10.10.0.73; kensho-nw3=192.168.10.144; |
| | test-nw2=100.80.0.35; test-nw1=100.60.0.22 |
| config_drive | True |
| created | 2019-08-27T04:09:54Z |
| flavor | sa.tiny |
| hostId | 977b3d3079fd83606c0d7535491e0429277c37ecf96b6c8b537c2b86 |
| id | 09a55ec1-bb1e-42ba-bb68-015c9038cf72 |
| image | testvm01.qcow2 (596a6b56-087f- |
| | 439e-a196-acc844bea944) |
| key_name | ansible-key |
| name | testvm01 |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| project_id | 137e88f78dc84d3f964dd0af9f5f7a60 |
| properties | |
| status | ACTIVE |
| updated | 2019-08-27T05:00:56Z |
| user_id | 82234229cf814541a078e6d4055a8bcc |
+--------------------------------------+-------------------------------------------------------------------+
## VMにログインし、eth4インターフェースが付いているのを確認⇒IP付与。
[root@testvm01 ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:42:0b:00 brd ff:ff:ff:ff:ff:ff
inet 172.21.0.123/24 brd 172.21.226.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe42:b00/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:10:b4:f9 brd ff:ff:ff:ff:ff:ff
inet 10.10.0.73/23 brd 100.64.145.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe10:b4f9/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:e6:93:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.144/26 brd 172.25.113.191 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fee6:93d8/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:b0:72:9c brd ff:ff:ff:ff:ff:ff
inet 100.60.0.22/24 brd 100.64.96.255 scope global eth3
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:feb0:729c/64 scope link
valid_lft forever preferred_lft forever
6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether fa:16:3e:55:23:27 brd ff:ff:ff:ff:ff:ff
[root@testvm01 ~]#
[root@testvm01 ~]# cd /etc/sysconfig/network-scripts/
[root@testvm01 network-scripts]# vi ifcfg-eth4
DEVICE=eth4
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=100.80.0.35
PREFIX=24
[root@testvm01 network-scripts]#
[root@testvm01 network-scripts]# ifup eth4
You have new mail in /var/spool/mail/root
[root@testvm01 network-scripts]#
[root@testvm01 network-scripts]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:42:0b:00 brd ff:ff:ff:ff:ff:ff
inet 172.21.0.123/24 brd 172.21.226.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe42:b00/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:10:b4:f9 brd ff:ff:ff:ff:ff:ff
inet 10.10.0.73/23 brd 100.64.145.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe10:b4f9/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:e6:93:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.144/26 brd 172.25.113.191 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fee6:93d8/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:b0:72:9c brd ff:ff:ff:ff:ff:ff
inet 100.60.0.22/24 brd 100.64.96.255 scope global eth3
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:feb0:729c/64 scope link
valid_lft forever preferred_lft forever
6: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether fa:16:3e:55:23:27 brd ff:ff:ff:ff:ff:ff
inet 100.80.0.35/24 brd 100.65.96.255 scope global eth4
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe55:2327/64 scope link
valid_lft forever preferred_lft foreve
[root@testvm01 network-scripts]# exit
logout