pikesaku’s blog

個人的な勉強メモです。記載内容について一切の責任は持ちません。

OpenStack環境構築メモ(Keystoneセットアップ)

参考URL

OpenStack Docs: Highly available Identity API
OpenStack Docs: Keystone Installation Tutorial
 
RabbitMQクラスタセットアップ実施後に、以下作業をコントローラ3台に実施する。
 

①DB作成

以下を1号機で実施

$ mysql -uroot -p[DB_PASSWORD] -e 'CREATE DATABASE keystone;'
$ mysql -uroot -p[DB_PASSWORD] -e "GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY '[KEYSTONE_DB_PASSWORD]';"
$ mysql -uroot -p[DB_PASSWORD] -e "GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'%' IDENTIFIED BY '[KEYSTONE_DB_PASSWORD]';"

 

パッケージインストール

$ sudo apt -y install keystone apache2 libapache2-mod-wsgi

 

設定ファイル編集

$ sudo crudini --set /etc/keystone/keystone.conf database connection 'mysql+pymysql://keystone:[KEYSTONE_DB_PASSWORD]@cnt/keystone'
$ sudo crudini --set /etc/keystone/keystone.conf token provider 'fernet'
$ sudo crudini --set /etc/keystone/keystone.conf cache memcache_servers 'cnt1:11211,cnt2:11211,cnt3:11211'
$ sudo crudini --set /etc/keystone/keystone.conf DEFAULT transport_url 'rabbit://cnt1:5672,cnt2:5672,cnt3:5672'
$ sudo crudini --set /etc/keystone/keystone.conf oslo_messaging_notifications transport_url 'rabbit://cnt1:5672,cnt2:5672,cnt3:5672'
$ sudo crudini --set /etc/keystone/keystone.conf oslo_messaging_rabbit rabbit_retry_interval 1
$ sudo crudini --set /etc/keystone/keystone.conf oslo_messaging_rabbit rabbit_retry_backoff 2
$ sudo crudini --set /etc/keystone/keystone.conf oslo_messaging_rabbit rabbit_max_retries 0
$ sudo crudini --set /etc/keystone/keystone.conf oslo_messaging_rabbit rabbit_durable_queues 'true'
$ sudo crudini --set /etc/keystone/keystone.conf oslo_messaging_rabbit rabbit_ha_queues 'true'

※以下URLに従いmemcached, rabbitmq連携部分の冗長化設定を実施
OpenStack Docs: Installing Memcached
OpenStack Docs: Messaging service for high availability
 

Keystone用DB展開 & キーレポジトリ初期化 & Keystone設定

$ sudo su -
# su -s /bin/sh -c "keystone-manage db_sync" keystone
# keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone
# keystone-manage credential_setup --keystone-user keystone --keystone-group keystone
# keystone-manage bootstrap --bootstrap-password [ADMIN_PASSWORD] --bootstrap-admin-url http://cnt.local:35357/v3/ --bootstrap-internal-url http://cnt.local:5000/v3/ --bootstrap-public-url http://cnt.pikesaku.net:5000/v3/ --bootstrap-region-id RegionPike

※fernet_setup, credential_setupはDB変更しない。/etc/keystone/fernet-keys, /etc/keystone/credential-keys配下のファイルを更新した為、上記コマンドは全サーバで実行した方が良いと判断。実際に試験を実施し、上記を全サーバで実行しないと、1号機apache停止時に正常動作を確認できなかった。
 

Apache設定変更 & 再起動

$ echo 'ServerName cnt.local' | sudo tee -a /etc/apache2/apache2.conf
$ sudo systemctl restart apache2

 

KeystoneのHAProxyへの組み込み

設定ファイル編集
/etc/haproxy/haproxy.cfgに以下を追加

listen keystone_admin_endpoint
	bind 192.168.1.50:35357
	balance source
	option tcpka
	option httpchk
	option tcplog
	server cnt1 192.168.1.51:35357       inter 2000 rise 2 fall 5
	server cnt2 192.168.1.52:35357 check inter 2000 rise 2 fall 5
	server cnt3 192.168.1.53:35357 check inter 2000 rise 2 fall 5

listen keystone_internal_endpoint
	bind 192.168.1.50:5000
	balance source
	option tcpka
	option httpchk
	option tcplog
	server cnt1 192.168.1.51:5000       inter 2000 rise 2 fall 5
	server cnt2 192.168.1.52:5000 check inter 2000 rise 2 fall 5
	server cnt3 192.168.1.53:5000 check inter 2000 rise 2 fall 5

listen keystone_public_endpoint
	bind 192.168.0.50:5000
	balance source
	option tcpka
	option httpchk
	option tcplog
	server cnt1 192.168.0.51:5000       inter 2000 rise 2 fall 5
	server cnt2 192.168.0.52:5000 check inter 2000 rise 2 fall 5
	server cnt3 192.168.0.53:5000 check inter 2000 rise 2 fall 5

 

haproxy再起動

$ sudo systemctl restart haproxy

 

動作確認

1号機で以下ファイルを生成
./adminrc

export OS_PROJECT_DOMAIN_NAME=Default
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=[ADMIN_PASSWORD]
export OS_AUTH_URL=http://cnt.local:35357/v3
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2

 
1号機で以下コマンドを実行

$ source ./adminrc

 
以下コマンドが正常に実行できることを確認

$ openstack project list -c Name
+-------+
| Name  |
+-------+
| admin |
+-------+

 
1号機のapacheを停止し、上記が正常に実行できることを確認
2号機のapacheを停止し、上記が正常に実行できることを確認
3号機のapacheを停止し、上記が失敗することを確認(以下エラーが出る)

$ openstack project list -c Name
Failed to discover available identity versions when contacting http://cnt.local:35357/v3. Attempting to parse version from URL.
Unable to establish connection to http://cnt.local:35357/v3/auth/tokens: ('Connection aborted.', BadStatusLine("''",))

 

備考

HAProxyはSNATする。

APIは以下URL参照
OpenStack Docs: Mapping of policy target to API

全コントローラを停止した場合、起動時に以下オペレーションが必要
 
rabbitmq起動
2,3号機で以下コマンド実行

$ sudo systemctl start rabbitmq-server

 
mariadb起動
最後に停止したサーバで以下コマンド実行

$ sudo galera_new_cluster 

他サーバで以下コマンド実行

$ sudo systemctl start mariadb

OpenStack環境構築メモ(memcachedセットアップ)

memcachedインストール

$ sudo apt -y install memcached python-memcache

 

②設定ファイル編集

sedで置換後のIPアドレスはノード毎に適宜変更

$ sudo sed -i -e 's/-l 127\.0\.0\.1/-l 192.168.1.51/' /etc/memcached.conf

 

memcached再起動・動作確認

$ sudo systemctl restart memcached
$ sudo netstat -lpnt | egrep memcache
tcp        0      0 192.168.0.51:11211      0.0.0.0:*               LISTEN      3160/memcached 
$

OpenStack環境構築メモ(HAProxyセットアップ & Pacemaker組込)

カーネルパラメタ変更

$ echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

 

②HAProxyインストール

$ sudo apt -y install haproxy

 

③HAproxy設定ファイル編集

/etc/haproxy/haproxy.cfg

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	daemon
	maxconn 4000

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# Default ciphers to use on SSL-enabled listening sockets.
	# For more information, see ciphers(1SSL). This list is from:
	#  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
	ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
	ssl-default-bind-options no-sslv3

defaults
	log	global
        timeout connect 5000
        timeout client  50000
        timeout server  50000

listen galera_cluster
	bind 192.168.1.50:3306
	balance source
	mode tcp
	option tcpka
	option mysql-check user haproxy
	server cnt1 192.168.1.51:3306             inter 2000 rise 2 fall 5
	server cnt2 192.168.1.52:3306 check inter 2000 rise 2 fall 5
	server cnt3 192.168.1.53:3306 check inter 2000 rise 2 fall 5

 
④HAProxyのDB死活監視で利用するユーザーをDBに登録
以下は1号機のみで実施

$ mysql -uroot -pPASSWORD -e "create user 'haproxy'@'192.168.1.51';"
$ mysql -uroot -pPASSWORD -e "create user 'haproxy'@'192.168.1.52';"
$ mysql -uroot -pPASSWORD -e "create user 'haproxy'@'192.168.1.53';"

 
⑤PacemakerリソースとしてHAProxyを組み込む
以下は1号機のみで実施

$ sudo crm configure primitive haproxy lsb:haproxy op monitor interval="1s"
$ sudo crm configure colocation vip-with-haproxy inf: vip-public vip-local haproxy
$ sudo crm configure order haproxy-after-vip mandatory: vip-public vip-local haproxy

※上記のvip-publicとvip-localは、Pacemaker & Corosyncセットアップ実施時に定義したもの

mariadbのmy.cnfについて

疑問点

 
my.cnfにはセクションが色々ある。どの機能が、どのセクションを読み込むの?
mysqldセクションが複数ファイルに描かれる場合もあり。この場合は、どっちが有効?
my.cnfファイルが複数ある場合あり、どれが読まれるの?
 

回答

 
mariadb.com
 
コマンド毎に読み込まれるセクションが決まっている。
どのセクションを読むかは、以下コマンドで確認できる。

$ [コマンド] --help --verbose

 
mysqldの場合、以下メッセージが出力される。

$ mysqld --help --verbose
〜省略〜
Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf 
The following groups are read: mysqld server mysqld-10.2 mariadb mariadb-10.2 client-server galera
〜省略〜

 
以下を確認できる

  • 読み込まれる設定ファイル・順番
  • 読み込まれるセクション

 
更に上記URLによると

各設定ファイルは コマンド --help --verbose が示した順番で、一度ずつ読み込まれます。 各設定オプションは、その出現順にコマンドラインオプションで指定するのと同じ効果があります。

 
最後に読み込まれたパラメタが有効になるっぽい
 
有効なパラメタは以下方法で確認できる。

$ my_print_defaults [コマンド]

 

$ my_print_defaults mysqld|egrep max_connections
--max_connections=100
--max_connections=4096
$ mysql -s -N -uroot -pPASSWORD -e 'show variables' | egrep max_connections
extra_max_connections	1
max_connections	4096
$ 

 
同一パラメタが複数指定された場合は、最後に読み込まれたものが有効

OpenStack気づきメモ

neutron.confのcore_pluginの設定値

一般的ユースケースの設定はml2(?)
openvswitch指定はobsolete(?)
7.5. Networking Service の設定
以下記述があり

モノリシックな Open vSwitch プラグインは非推奨で、将来のリリースでは廃止される予定となっています。この機能は、代わりに ML2 のメカニズムに再実装されています。

ml2を指定すべき

OpenStack Neutron冗長化メモ

参考URL

 
OpenStack Docs: Configuring the networking services
OpenStack Docs: High-availability for DHCP
OpenStack Docs: Open vSwitch: High availability using VRRP
 

DHCPエージェント冗長化

 
DHCPエージェントはアプリ自体で冗長化に対応
1エージェントの複数NW対応・1NWに複数エージェント割当が可能
手動でエージェントを追加したり、無効化したり削除したり可能
1ネットワークにつき起動するDHCPエージェント数を設定ファイルで指定可能
linuxbridge利用時の設定サンプルのみ記載(openvswitch利用時は設定不可???)
DHCPエージェントはコンピュートノードで、L3エージェントはネットワークノードで動作(?)
OpenStack Docs: Open vSwitch: High availability using VRRPの図より
 

L3エージェント冗長化

 
L3HA
self service networkはインスタンスが直結されるテナントNWを意味する
L3エージェント=仮想ルーター, DHCPエージェント、メタデータエージェントのこと
仮想ルーターVRRP冗長化(Active & Standby)

f:id:pikesaku:20171029101735p:plain

VRRPのHeartBeatはha-eb820380-40@if21を使う? L3HAで作られるNWと想定される為

f:id:pikesaku:20171029101857p:plain
[:pla

ha-eb820380-40@if21は物理IFとしてvxlan nwを通る(?)MTUが1450になってる為
この169.X.X.Xがhidden project netowork(=tenant nw?)
OpenStack Docs: 分散仮想ルーティングと VRRP の組み合わせ

通常動作中は、マスタールーターは定期的に heartbeat パケットを、隠しプロジェクトネットワーク経由で送信します。隠しプロジェクトネットワークには、1 つのプロジェクトのすべての HA ルーターが接続されます。

しかも、L3HAとDVR排他ではなくなった?

従来の HA ルーターと同じく、 DVR/SNAT HA ルーターでは SNAT サービスが別のノードで動作する L3 エージェントのバックアップ DVR/SNAT HA ルーターに迅速にフェールオーバーされます。

 
こんな記述あり。まだ使うのは危険そうな。。。。

実験的な機能で、ドキュメントも不十分です。

 

既知の制限
現時点では、分散のみ、HA のみ、レガシーモードのルーターから分散 HA ルーターへの移行には対応していません。ルーターは分散 HA モードで作成しなければいけません。逆方向の移行にも対応していません。分散 HA ルーターを、分散のみ、HA のみ、レガシーモードに設定し直すことはできません。
L2 population と分散 HA ルーターが期待通りに連携しない場面がいくつかあります。これらの場面は、 HA のみのルーターと L2 population がうまく連携できない場面と同じです。

   
L3HAのハートビートはテナントNWを通ることは以下URL資料にも記載あり。
L3HA-VRRP-20141201
 
このサイトも情報量豊富
Mirantis OpenStack DVR 徹底解剖(第一回) - Qiita
DVRの場合のEast-West通信は同一仮想ルータに接続された別サブネット間通信のことだろう。
OpenStack Docs: シナリオ: Open vSwitch を使った基本構成
East-West通信説明は、同一仮想ルータに接続された別サブネット間通信のことと想定。
別仮想ルータに接続されたインスタンス間通信(Floating-IP経由)は、今まで通りネットワークノード経由(?)
 

感想

 
公式Docはわかりづらい!
 
知っているようで知らないNeutron -仮想ルータの冗長と分散- - OpenStack最新情報セミナー 2016年3月 - SSSSLIDE
非常にわかりやすい!!!
 
コラム - クラウド時代のオープンソース実践活用 | 第57回 OpenStack Neutronの新機能!DVRとL3HA(VRRP)|CTC教育サービス 研修/トレーニング
DVR・L3HA概要を知る上でわかりやすい。
※DVR・L3HAは同じ時期にリリースされた機能。
 
OpenStackのDVRを利用してネットワーク機能を高可用化 | テクノロジーコラム | 情報畑でつかまえて
このへんも要チェック
 
採用すべき冗長化方式は?
L3HAか。。。。OpenStack公式DocのNeutorn冗長化もL3HA。
OpenStack Docs: Open vSwitch: High availability using VRRP
meta-dataとdhcpエージェントはコンピュートノードで複数起動可能。それだけで冗長化OKってこと?
DVRとの併用はまだ試験機能だろう。

Rabbitmqキューミラー環境構築・検証

Rabbitmqを冗長化する方法として、キューミラー方式があり。その動作検証をする。
 

環境

サーバ台数: 3台(ホスト名はcnt1,2,3)
OS: Ubuntu16.04LTS
 

環境構築手順

①RabbitMQ Serverインストール&停止

$ sudo apt -y install rabbitmq-server 
$ sudo systemctl stop rabbitmq-server

 

Erlang クッキーファイル設定

/var/lib/rabbitmq/.erlang.cookie
3台のサーバで上記ファイル内容を同一にする
 

③rabbitmq-server起動

$ sudo systemctl start rabbitmq-server.service

 

④2,3号機で以下を実施

$ sudo rabbitmqctl stop_app
$ sudo rabbitmqctl join_cluster --ram rabbit@cnt1
$ sudo rabbitmqctl start_app

※モードはramとdiscの2種類あり。ramモードはキューデータをramに格納(電源障害時データ保護なし)。discモードはramとディスク両方に格納。デフォルトはdiscモード。HAキューミラー構成時は、1台でもdiscがあれば保護レベルは担保されるため、2,3号機はramモードで起動。各モードはmanのrabbitmqctlを参照。
 

⑤以下コマンドを実行してクラスタ状態を確認

$ sudo rabbitmqctl cluster_status
Cluster status of node rabbit@cnt2 ...
[{nodes,[{disc,[rabbit@cnt1]},{ram,[rabbit@cnt3,rabbit@cnt2]}]},
 {running_nodes,[rabbit@cnt3,rabbit@cnt1,rabbit@cnt2]},
 {cluster_name,<<"rabbit@cnt1.pikesaku.net">>},
 {partitions,[]}]
$

※running_nodesに3サーバあること
 
⑥キューミラーの設定。どのサーバで実行してもOK

$ sudo rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'

※この(?!amq¥.)は以下URLの「先読み否定グループ」。"amq."で始まるもの以外全ての意味。
正規表現サンプル集

set-policyの引数は、ポリシー名・パターンマッチ・定義

ha-modeにallを指定すると全ノードにキューデータをミラーする。

 

検証

 

システム起動時の動作

システム起動時はクラスタの親である1号機が先に起動している状態で、2,3号機を起動する必要あり。
2,3号機はrabbitmqctl join_clusterで1号機のクラスタに属する形態。しかも1号機がdiscモードで永続的にデータを持っているため、上記動作は理解できる。
クラスタ構成の情報は、各ノードが/var/lib/rabbitmq/mnesia配下のファイルで保持している。
例)cnt2の/var/lib/rabbitmq/mnesia/rabbit@cnt2/cluster_nodes.config

{[rabbit@cnt1,rabbit@cnt2,rabbit@cnt3],[rabbit@cnt1]}.

 

キュー出し入れ動作

キュー送信ツール(キュー永続化無効)

#!/usr/bin/env python

import pika
import sys

args = sys.argv

if len(args) != 3:
  print('Error: invalid argment')
  exit()

h = args[1]
q = args[2]

#credentials = pika.PlainCredentials('hogehoge', 'hogehoge')
#connection = pika.BlockingConnection(pika.ConnectionParameters(host=h, credentials=credentials))

connection = pika.BlockingConnection(pika.ConnectionParameters(host=h))
channel = connection.channel()
channel.queue_declare(queue=q, durable=True)
prop = pika.BasicProperties(delivery_mode=2)
channel.basic_publish(exchange='',
                      routing_key=q,
                      body='Hello World!',
                      properties=prop)
print(" [x] Sent 'Hello World!'")
connection.close()

 
キュー送信ツール(キュー永続化有効)

 
キュー取り出しツール

#!/usr/bin/env python
import pika
import sys

args = sys.argv

if len(args) != 3:
  print('Error: invalid argment')
  exit()

h = args[1]
q = args[2]

connection = pika.BlockingConnection(pika.ConnectionParameters(host=h))
channel = connection.channel()
channel.queue_declare(queue=q)
def callback(ch, method, properties, body):
    print(" [x] Received %r" % body)
channel.basic_consume(callback,
                      queue=q,
                      no_ack=True)
print(' [*] Waiting for messages. To exit press CTRL+C')
channel.start_consuming()

 

メモ

キューが全サーバにミラーされるのは確認できた。しかし異常系動作がしっかり把握できず。(ram/discモード・永続化等)
以下記事をしっかり読み込み把握する必要あり。

項目 URL
チュートリアル RabbitMQ - Getting started with RabbitMQ
ユーザー認証 RabbitMQ - Access Control (Authentication, Authorisation) in RabbitMQ
アクセス制御 RabbitMQ - Access Control (Authentication, Authorisation) in RabbitMQ

 
rabbitmq-server接続時にユーザー未指定の場合、guest扱いになる。guestはデフォルトでリモートから操作不可。リモートからユーザー未指定で操作するには、以下ファイルを新設し設定を変更する必要あり。
/etc/rabbitmq/rabbitmq.config

[
  {rabbit, [
    {loopback_users, []}
  ]}
].

参考
pika - Unable to access RabbitMQ server from other clients on the network due to authentication error - Stack Overflow
 
管理コマンドは以下を参考
RabbitMQ管理コマンド(rabbitmqctl)使い方 - Qiita
 
チュートリアル和訳もあり
RabbitMQ チュートリアル2(ワークキュー) - Qiita