pikesaku’s blog

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

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

OpenStack環境構築メモ(RabbitMQクラスタセットアップ)

①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とディスク両方に格納。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."で始まるもの以外全ての意味。
正規表現サンプル集
 

補足

システム起動時はクラスタの親である1号機が先に起動している状態で、2,3号機を起動する必要あり。
2,3号機はrabbitmqctl join_clusterで1号機のクラスタに属している。また1号機がdiscモードであり永続的にデータを持っている。

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バージョンを指定すればインストール手順が表示される。
f:id:pikesaku:20171021173009p:plain