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)
VRRPのHeartBeatはha-eb820380-40@if21を使う? L3HAで作られるNWと想定される為
[: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を冗長化する方法として、キューミラー方式があり。その動作検証をする。
参考URL
かっぱのほげふが | RabbitMQ のクラスタ構成を体感する
涙の自腹課金検証シリーズ第一弾：RabbitMQ クラスタ HA モード 3 パターンを速攻試す · GitHub
RabbitMQ - Highly Available (Mirrored) Queues
環境
サーバ台数: 3台(ホスト名はcnt1,2,3)
OS: Ubuntu16.04LTS
環境構築手順
①RabbitMQ Serverインストール＆停止
$ sudo apt -y install rabbitmq-server $ sudo systemctl stop rabbitmq-server
③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モード・永続化等)
以下記事をしっかり読み込み把握する必要あり。
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
OpenStack環境構築メモ(RabbitMQクラスタセットアップ)
参考
OpenStack Docs: Messaging service for high availability
RabbitMQ - Installing on Debian / Ubuntu
かっぱのほげふが | RabbitMQ のクラスタ構成を体感する
RabbitMQ - Highly Available (Mirrored) Queues
memcachedセットアップ実施後に、以下作業をコントローラ3台に実施する。
①RabbitMQ Serverインストール＆停止
$ sudo apt -y install rabbitmq-server $ sudo systemctl stop rabbitmq-server
③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とディスク両方に格納。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サーバあること
⑥キューミラー設定
1号機で以下を実施
$ sudo rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{"ha-mode": "all"}'※この(?!amq¥.)は以下URLの「先読み否定グループ」。"amq."で始まるもの以外全ての意味。
正規表現サンプル集
OpenStack環境構築メモ(Pacemaker & Corosyncセットアップ)
参考
OpenStack Docs: Pacemaker cluster stack
DBクラスタセットアップ実施後に、以下作業をコントローラ3台に実施する。
①Pacemaker & Corosyncインストール
$ sudo apt -y install crmsh
②設定ファイル編集
/etc/corosync/corosync.conf
totem {
version: 2
cluster_name: debian
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
interface {
ringnumber: 0
bindnetaddr: 192.168.1.0
broadcast: yes
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
expected_votes: 2
}
nodelist {
node {
ring0_addr: 192.168.1.51
nodeid: 1
}
node {
ring0_addr: 192.168.1.52
nodeid: 2
}
node {
ring0_addr: 192.168.1.53
nodeid: 3
}
}
③Corosync再起動
$ sudo systemctl stop corosync $ sudo systemctl start corosync
④動作確認
$ sudo corosync-cfgtool -s Printing ring status. Local node ID 1 RING ID 0 id = 192.168.1.51 status = ring 0 active with no faults
※statusがno faultsであること
$ sudo corosync-cmapctl runtime.totem.pg.mrp.srp.members runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(192.168.1.51) runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.1.status (str) = joined runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip(192.168.1.52) runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.2.status (str) = joined runtime.totem.pg.mrp.srp.members.3.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.3.ip (str) = r(0) ip(192.168.1.53) runtime.totem.pg.mrp.srp.members.3.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.3.status (str) = joined
※statusがjoinedであること
⑤Pacemaker再起動
$ sudo systemctl restart pacemaker
⑥Pacemaker起動確認
$ sudo crm_mon -1 Last updated: Sat Nov 4 00:27:14 2017 Last change: Sat Nov 4 00:25:10 2017 by hacluster via crmd on cnt1 Stack: corosync Current DC: cnt1 (version 1.1.14-70404b0) - partition with quorum 3 nodes and 0 resources configured Online: [ cnt1 cnt2 cnt3 ]
※Onlineに3台表示されること
⑦Pacemaker設定
cnt1のみで以下を実施
プロパティ設定
$ sudo crm configure property pe-warn-series-max="1000" pe-input-series-max="1000" pe-error-series-max="1000" cluster-recheck-interval="5min" no-quorum-policy="ignore" stonith-enabled=false $
VIP設定
$ sudo crm configure primitive vip-public ocf:heartbeat:IPaddr2 params ip="192.168.0.50" cidr_netmask="24" op monitor interval="30s" $ sudo crm configure primitive vip-local ocf:heartbeat:IPaddr2 params ip="192.168.1.50" cidr_netmask="24" op monitor interval="30s"
UbuntuにMariadbレポジトリ設定をする方法
方法
上記URLでディストリビューション、OSバージョン、Mariadbバージョンを指定すればインストール手順が表示される。
OpenStack環境構築メモ(DBクラスタセットアップ)
リンク元ページ
pikesaku.hatenablog.com
コントローラ基本セットアップ実施後に、以下作業をコントローラ3台に実施する。
①MariaDBセットアップ
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8 $ sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://ftp.yz.yamagata-u.ac.jp/pub/dbms/mariadb/repo/10.2/ubuntu xenial main' $ sudo apt update $ sudo apt -y install mariadb-server python-pymysql
③設定ファイル編集
以下ファイルを新規に作成
/etc/mysql/mariadb.conf.d/galera.cnf
※bind-address, wsrep_node_address, wsrep_node_nameはノード毎に適宜変更
※bind-addressを0.0.0.0はNG。後で設定するHAProxy・PacemakerのVIP設定をすると起動しなくなる。
Nov 04 14:35:46 cnt3 mysqld[1836]: 2017-11-04 14:35:44 140114370193600 [ERROR] Can't start server: listen() on TCP/IP port: Address already in use Nov 04 14:35:46 cnt3 mysqld[1836]: 2017-11-04 14:35:44 140114370193600 [ERROR] listen() on TCP/IP failed with error 98 Nov 04 14:35:46 cnt3 mysqld[1836]: 2017-11-04 14:35:44 140114370193600 [ERROR] Aborting'
galera.cnf内容
[galera] bind-address = 192.168.1.51 max_connections = 4096 collation_server = utf8mb4_general_ci character_set_server = utf8mb4 binlog_format = row wsrep_on = ON wsrep_provider = "/usr/lib/libgalera_smm.so" wsrep_provider_options = "pc.recovery=TRUE;gcache.size=300M" wsrep_cluster_name = mycluster wsrep_cluster_address = "gcomm://192.168.1.51,192.168.1.52,192.168.1.53" wsrep_sst_method = rsync wsrep_node_address = 192.168.1.51 wsrep_node_name = cnt1 wsrep_slave_threads = 1 default_storage_engine = InnoDB innodb_flush_log_at_trx_commit = 0 innodb_autoinc_lock_mode = 2 innodb_file_per_table = on
④1号機でサービス起動
$ sudo galera_new_cluster
⑤2,3号機でサービス起動
$ sudo systemctl start mariadb
⑥クラスタ確認
3台のコントローラで以下コマンド実行。valueが3であることを確認。
$ mysql -uroot -p[DB_PASSWORD] -e "SHOW STATUS LIKE 'wsrep_cluster_size';" +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+
補足
システム起動時はサービス起動に失敗する。以下作業が必要。
①一番最後に停止したサーバで以下コマンドを実行
$ sudo galera_new_cluster
②他サーバで以下コマンドを実行
$ sudo systemctl start mariadb
※一番最後に停止してないサーバで、galera_new_clusterを実行するとエラーになる。ログメッセージは以下。
WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .
※3台のサーバを同時に停止すると、一番最後に停止したサーバでgalera_new_clusterを実行しても上記エラーになる。この場合は、ログに従い/var/lib/mysql/grastate.datのsafe_to_bootstrapパラメタを1にして、再度galera_new_clusterを実行する。
