宇宙の晴れ上がり: OpenStack

ラベル OpenStack の投稿を表示しています。すべての投稿を表示

Cloud (OpenStack)用のCentOSイメージ

OpenStackのページやそこからの CentOSのダウンロードページから、取得可能。

ログインユーザ： centos
で、起動時に登録した公開キーでsshログインできる。

Ceilometerの監視間隔を変更する。

computeノードの/etc/ceilometer/pipeline.yamlを編集。

例： CPUの監視間隔を1分毎にする。

    - name: cpu_source
#      interval: 600
      interval: 60
      meters:
          - "cpu"
      sinks:
          - cpu_sink

Novaでホストを指定して、VMを起動する。

nova bootに以下のオプションを追加する。青字の部分を適宜変更。

--availability-zone nova:host_name

OpenstackのCeilometerで特定のVMに対するアラームを作成する例

下記では、eb79c816-8994-4e21-a26c-51d7d19d0e45 がVMのResource ID.

 
ceilometer alarm-create --name cpu-util-10min-50per --meter-name cpu_util --comparison-operator ge --threshold 50 --matching-metadata resource=eb79c816-8994-4e21-a26c-51d7d19d0e45 --period 600

OpenStackのDashboard (Horizon)のセッションタイムアウトを変更する

/etc/openstack-dashboard/local_settings.pyのSESSION_TIMEOUT変数を秒単位で設定する。

例：タイムアウトを365日にする。このファイルは、Python scriptの一部なので下記のようにPythonの式を用いることも可能。

SESSION_TIMEOUT = 3600 * 24 * 365

※実際は、他にも制限があるようで、上記の設定をしても数十分程度でやはりタイムアウトする。

OpenStackでGREトンネルを使った場合の問題に関する記事へのリンク

http://techbackground.blogspot.jp/2013/06/path-mtu-discovery-and-gre.html

OpenStackのglaceでコマンドラインでイメージを登録する例。

glance image-create --name ubuntu14-14.04.1-server --disk-format=raw --container-format=bare --is-public True --copy-from https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img

OpenStackのNovaですべてのテナントのリストを表示

$ nova list --all-tenant 1

OpenStackでコマンドラインでイメージを登録する例

$ glance image-create --name='image name' --is-public=true --container-format=bare --disk-format=qcow2 < file.img

イメージを標準入力から受け取るので、以下のようにcurlでダウンロードしながら、それを登録することもできる。

$ curl https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img | glance image-create --name='Ubuntu Server 14.04 LTS' --is-public=true --container-format=bare --disk-format=qcow2

OpenStackのNovaのログ出力をデバッグレベルにする

/etc/nova/nova.confのdebug=行の右辺をTrueにすると出力がデバッグレベルになる。ただし、かなりの量のログが記録されるので注意。

# Print debugging output (set logging level to DEBUG instead
# of default WARNING level). (boolean value)
#debug=false
debug=True

なお、ログは通常以下のディレクトリに作成される。
/var/log/nova

Amazon EC2とOpenStackでUser dataとMeta dataを取得する

EC2でのUser dataの取得方法。下記の例のようにインスタンスからWebアクセスで取得する。以下ではcurlを使用するが、HTTPでアクセスできる方法であればなんでもOK。

$ curl http://169.254.169.254/latest/user-data/

Meta dataも同様に下記のようにする。

$ curl http://169.254.169.254/latest/meta-data/

上記コマンドでは、取得できる項目やディレクトリが表示されるので、それらをURLに指定してGETすることで、その値を取得できる。例えば、ami-idなら、次のとおり。

$ curl http://169.254.169.254/latest/meta-data/ami-id

OpenStackでも上記EC2と同じ方法でuser dataとmeta dataを取得できる。さらに次のOpenStack独自のURLも使用可能である。

$ curl http://169.254.169.254/openstack/latest/user_data
$ curl http://169.254.169.254/openstack/latest/meta_data.json

他にも、passowrdとvendor_data.jsonも取得可能。

$ curl http://169.254.169.254/openstack/latest
meta_data.json
user_data
password
vendor_data.json

なお、169.254.169.254への通信ができない場合は、こちらの記事も参照。

OpenStackのGatewayのないネットワーク上のVMでuser dataとmeta data取得の為のrouteを設定する

OpenStackでは、AWS EC2と同様に169.254.169.254にhttpでアクセスできる。
Gatewayが設定されていないSubnetに接続されているゲストマシンから、それらの情報を取得するには次の設定をする。なお、構成としてNeutronを使用していることを前提とする。

/etc/neutron/dhcp_agent.iniに次の設定をする。
```
enable_isolated_metadata = True
```
neutron-dhcp-agentが実行されているマシン(いわゆるNetwork node)をリスタートする。
なお、下記のようにdhcp agentの再起動だけでよさそうにも思えるが、RDO(Havana)ではうまく行かなかった。
```
# service neutron_dhcp_agent restart
```
設定が正常に反映された場合、dnsmasqの--dhcp-optsfileに指定されている設定ファイルの内容は、次のように169.254.169.254への静的ルートを含む。
```
# cat /var/lib/neutron/dhcp/04911b6c-d75a-4744-b604-c99a342ca95f/opts
tag0,option:classless-static-route,169.254.169.254/32,192.168.150.101
tag0,249,169.254.169.254/32,192.168.150.101
```
ゲストマシンの起動

$ route 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.169.254 192.168.150.101 255.255.255.255 UGH   0      0        0 eth0
192.168.150.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0

nova-manageの基本コマンド

VMの一覧を表示。どのcompute node上で実行されているかを知ることができる。

# nova-manage vm list

ホスト(compute node)の一覧表示

# nova-manage host list

OpenStackのCeilometerを使う

メータの一覧を見る。

# ceilometer meter-list

測定値を見る。下記のにはメータ一覧のName列に指定される値のいずれかを指定する。

# ceilometer sample-list -m

特定のリソースIDのものを抽出する場合、-qオプションを利用する。

# ceilometer sample-list -m cpu -q 'resource_id=9e571f72-fc21-42a5-8899-a87736dda57a'

OpenStackのnovaコマンドでインスタンスを起動する

例: 青字の部分は適宜変更します。

$ nova boot --flavor 1 --key_name mykey --image  a7822d3f-5ba2-4248-9a3e-a946257b637c --security_group default --nic net-id=662fd507-eb19-4b98-a912-519e92846957 instance_name

flavaor一覧の調べ方

$ nova flavor-list

key一覧の調べ方

$ nova keypair-list

image一覧の調べ方

$ nova image-list

security group一覧の調べ方

$ nova secgroup-list

network一覧の調べ方

$ nova net-list

プロジェクト名（テナント名）の変更と、ホストの指定も含む例。

$ nova --os-tenant-id e318a792ec044e1a838b14ead24828b9 boot --flavor d6bb73d1-6b4f-42ea-858d-cd1b0d48dd15  --key_name mykey --image 5060bbcb-a361-4e5a-ac26-9864143050e5  --security_group default --nic net-id=6505d940-df5c-4b2e-8da0-dbeda4343cd0 --availability-zone nova:host instance_name

OpenStackのNeutronでfloating IPを設定する例

内部Networkの192.168.50.100を外部ネットワークにマッピングする例を示します。

まず、内部ネット192.168.50.100のIPをもっているportのPORT_IDを調べます。

# neutron port-list
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips                                                                             |
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------------+
| 02cd18bc-768b-4b9b-937b-40dfe66fe33e |      | fa:16:3e:41:3f:01 | {"subnet_id": "2cc97205-b498-4e53-8fe5-21dd6f5da317", "ip_address": "192.168.30.128"} |
| 897101af-581f-42da-b8b6-56b8352cf53f |      | fa:16:3e:b2:47:71 | {"subnet_id": "ad914263-519c-40eb-a9b4-421485e5ece3", "ip_address": "192.168.50.101"} |
| ace36996-0315-4a7d-8eaa-379bb67bd688 |      | fa:16:3e:95:40:18 | {"subnet_id": "ad914263-519c-40eb-a9b4-421485e5ece3", "ip_address": "192.168.50.100"} |
| bc538543-d817-48a9-9dd3-9803fe6cf058 |      | fa:16:3e:63:c9:12 | {"subnet_id": "ad914263-519c-40eb-a9b4-421485e5ece3", "ip_address": "192.168.50.1"}   |
+--------------------------------------+------+-------------------+---------------------------------------------------------------------------------------+

次で、以下のように実際にマッピングを作成します。

 # neutron floatingip-create --port-id ace36996-0315-4a7d-8eaa-379bb67bd688 --fixed-ip-address 192.168.50.100 ext-net
Created a new floatingip:
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    | 192.168.50.100                       |
| floating_ip_address | 192.168.30.129                       |
| floating_network_id | 2635ab5a-0784-4898-b91d-dbe1228f31cf |
| id                  | ba6e13f3-0768-4d8f-8cd6-91217ea558aa |
| port_id             | ace36996-0315-4a7d-8eaa-379bb67bd688 |
| router_id           | 612dafe5-c553-4103-a5d2-96e379ed2e50 |
| tenant_id           | 4df9786b5d044f5e8ae1593e105546d4     |
+---------------------+--------------------------------------+

別の方法

なお、次のようにfloating IPを作成して、その後、associateすることもできる。

# neutron floatingip-create ext-net
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    |                                      |
| floating_ip_address | 192.168.158.82                       |
| floating_network_id | 53fe6eb3-6558-47a5-a758-3b2aa1f102ce |
| id                  | b4cd47df-92e1-433d-b48f-152b79063984 |
| port_id             |                                      |
| router_id           |                                      |
| tenant_id           | c5f8ac76b2a541c09da7c0fa8f23c03f     |
+---------------------+--------------------------------------+
# neutron floatingip-associate b4cd47df-92e1-433d-b48f-152b79063984 ace36996-0315-4a7d-8eaa-379bb67bd688

上記こまんどの第二引数はfloatingipのID、第三引数はport_idを表す。

Openstack (neutron)がつくるNetwork Interfaceの関係

仮想マシン

OpenStackでneutronとopenvswitchを使った構成では、仮想マシン毎に以下のような4つのインターフェイスが作成される。最初の3文字まはた4文字が異なり後は同じ数値の組です。
なお、これは、nova.confに以下の設定がある場合です。

libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver

qbr655843be-3b
qvb655843be-3b
qvo655843be-3b
tap655843be-3b

これらは次のように接続されている。

tapから始まるI/FはQEMU (KVM)などが作るゲストOSに接続されている。それがqbrから始まるBridgeに接続されている。 Bridgeの構成は、次のようにbrctrlコマンドで確認できる。

# brctl show
bridge name              bridge id                           STP enabled     interfaces
qbr655843be-3b      8000.f258a8426856       no                      qvb655843be-3b
                                                                                                         tap655843be-3b

qvbとqvoは、virtual ethernet tunnel (veth)の両端のデバイスである。qvbはBridge側に、qvoはOpen vSwitch側に接続されている。

DHCP agent

DHCP agentのネットワーク構成を下図に示す。

テナントネットワークごとのDHCPサーバは、独自のnetwork namespaceで実行されている。それは、virtual ethernet tunnelを経由してグローバルなnetowrk namespaceでOpen vSwitchに接続される。
なお、network namespaceの一覧を表示させるには次のようにする

# ip netns
qdhcp-26ac80d0-9f3d-46bf-9c04-27ecdcbd7800
qrouter-f53f573b-5c5f-4136-af7b-c7879cde9ed3
qrouter-d1982370-acba-4861-b706-185ccfd52cce
qdhcp-6e1aec2f-ad9c-4aec-b49e-cc5a85a1f1e5

また、次のようにnetwork namespaceを指定して、コマンド実行することで、その空間でのinterface一覧を取得できる。

# ip netns exec qdhcp-26ac80d0-9f3d-46bf-9c04-27ecdcbd7800 ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

ns-9e1da44f-f2 Link encap:Ethernet  HWaddr FA:16:3E:AA:A4:B2
          inet addr:10.5.20.3  Bcast:10.5.20.255  Mask:255.255.255.0
          inet6 addr: fe80::f816:3eff:feaa:a4b2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:468 (468.0 b)  TX bytes:468 (468.0 b)

KVMをIntel CPUでネストして実行する

KVMをIntelプロセッサでネストして実行する設定

カーネル3.2以上を用意する
/etc/modprobe.d/kvm-nested.confに以下を設定する
再起動する

なお、再起動後、次のように、Yが表示されれば成功

# cat /sys/module/kvm_intel/parameters/nested 
Y

neutronコマンドがAuthentication requiredを返す際の対処法

neutronがAuthentication requiredを返してかつ、/var/log/neutron/server.logに次のような記録がある場合、古い認証キーが使われている可能性があります。

2014-01-26 16:16:15.038 2814 WARNING keystoneclient.middleware.auth_token [-] Verify error: Command 'openssl' returned non-zero exit status 4
2014-01-26 16:16:15.039 2814 WARNING keystoneclient.middleware.auth_token [-] Authorization failed for token 7cd65acbdf1048d97f6629c2614eb9f8

このような事は、OpenStackコンポーネントのアップデートなどを繰り返しているうちに発生することがあります。対処法は、/var/lib/neutron/keystone-signingを削除(あるいは別名に）します。

OpenstackのHorizonでSomething went wrong!と表示される時の対処法

下記のような画面が表示される場合、アクセスしたホストが許可されてない場合があります。

アクセスが許可されていない場合、/var/log/horizon/horizon.logに次のようなログが出ています。

2014-01-25 23:13:34,980 21326 ERROR django.request Internal Server Error: /dashboard/
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/django/core/handlers/base.py", line 89, in get_response
    response = middleware_method(request)
  File "/usr/lib/python2.6/site-packages/django/middleware/common.py", line 55, in process_request
    host = request.get_host()
  File "/usr/lib/python2.6/site-packages/django/http/__init__.py", line 223, in get_host
    "Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS): %s" % host)
SuspiciousOperation: Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS): 192.168.158.20

上記に該当する場合、/etc/openstack-dashboard/local_settingsのALLOWED_HOSTS行に上記のログで表示されている最後の部分（青色で強調）を追加するとうまくいきます。
例）192.168.158.20からのアクセスを許可する場合、青字の部分を追加

ALLOWED_HOSTS = ['192.168.158.20', '192.168.0.10', 'ika.localdomain', 'localhost', ]

最後に、httpd (apache)を再起動します。 RedHat系ならコマンドラインで、

# service httpd restart

なお、これはHorizonというよりDjangoのアクセス制御機構に起因する問題です。

登録: 投稿 (Atom)

宇宙の晴れ上がり

Cloud (OpenStack)用のCentOSイメージ

Ceilometerの監視間隔を変更する。

Novaでホストを指定して、VMを起動する。

OpenstackのCeilometerで特定のVMに対するアラームを作成する例

OpenStackのDashboard (Horizon)のセッションタイムアウトを変更する

OpenStackでGREトンネルを使った場合の問題に関する記事へのリンク

OpenStackのglaceでコマンドラインでイメージを登録する例。

OpenStackのNovaですべてのテナントのリストを表示

OpenStackでコマンドラインでイメージを登録する例

OpenStackのNovaのログ出力をデバッグレベルにする

Amazon EC2とOpenStackでUser dataとMeta dataを取得する

OpenStackのGatewayのないネットワーク上のVMでuser dataとmeta data取得の為のrouteを設定する

nova-manageの基本コマンド

OpenStackのCeilometerを使う

OpenStackのnovaコマンドでインスタンスを起動する

OpenStackのNeutronでfloating IPを設定する例

別の方法

Openstack (neutron)がつくるNetwork Interfaceの関係

仮想マシン

DHCP agent

KVMをIntel CPUでネストして実行する

neutronコマンドがAuthentication requiredを返す際の対処法

OpenstackのHorizonでSomething went wrong!と表示される時の対処法

人気の投稿

ブログアーカイブ

ラベル

別の方法

仮想マシン

DHCP agent

人気の投稿

ブログ アーカイブ

ラベル

ブログアーカイブ