pikesaku’s blog

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

Ubuntu 16.04LTSメモ(時刻同期)

systemd-timesyncd利用する場合

 
ntpインストール不要。
ntp/chronyパッケージと異なりSNTPによるクライアント機能のみ。
 

設定ファイルは以下

/etc/systemd/timesyncd.conf

[Time]
#NTP=
#FallbackNTP=ntp.ubuntu.com

NTP、FallbackNTPにNTPサーバを設定。
デフォルトは未設定のため、設定する必要あり。

$ sudo cp -p /etc/systemd/timesyncd.conf  /etc/systemd/timesyncd.conf_org
$ sudo crudini --set /etc/systemd/timesyncd.conf Time NTP "0.ubuntu.pool.ntp.org"
$ sudo crudini --set /etc/systemd/timesyncd.conf Time FallbackNTP "1.ubuntu.pool.ntp.org 2.ubuntu.pool.ntp.org 3.ubuntu.pool.ntp.org"
$ sudo systemctl restart systemd-timesyncd.service

 

起動デーモンは以下
/lib/systemd/systemd-timesyncd

 

systemd-timesyncdの詳細は以下参照

systemd-timesyncd - ArchWiki
 

chrony利用する場合

 

$ sudo apt install chrony
$ systemctl start chrony

自動起動設定は不要。
chronyはsystemdに対応しておらず、/etc/init.d配下に起動スクリプトがあり。
systemdは、ここに起動スクリプトを置いた場合、起動する仕様があり。
そのため自動起動設定は不要。
alpha.mixi.co.jp

OpenStack環境構築メモ

冗長化実装方式

 

方針

ステートレスなサービスはActive/ActiveとしHAProxy(負荷分散)経由の冗長化
 

種別 サービス名 実装方式 URL
共通バックエンド DB Galera Cluster https://docs.openstack.org/ha-guide/shared-database.html
共通バックエンド AMQ HAキュー https://docs.openstack.org/ha-guide/shared-messaging.html
共通バックエンド Memcached クライアントマルチサーバ参照 https://docs.openstack.org/ha-guide/controller-ha-memcached.html
負荷分散 HAProxy Pacemaker https://docs.openstack.org/ha-guide/intro-ha.html#stateless-versus-stateful-services
https://docs.openstack.org/ha-guide-draft/control-plane-stateless.html
https://wiki.openstack.org/wiki/HAGuideImprovements/TOC
https://www.slideshare.net/sriramhere/open-stack-ha-theory-to-reality
OpenStack API Keystone
Nova
Glance
Neutron
Cinder
Ceilometer
負荷分散(HAProxy) 同上
OpenStack Process Cinder-Volumes(ステートフル) Pacemaker https://docs.openstack.org/ha-guide/storage-ha-block.html
OpenStack Process Ceilometer Central Agent(ステートフル) Tooz https://docs.openstack.org/ha-guide/controller-ha-telemetry.html

 

環境

 
f:id:pikesaku:20171105144048p:plain
 
システム構成ホスト & IPアドレス一覧

ホスト名 Public Manage/Storage Private1 説明
router 192.168.0.1 - - ルータ兼DNSサーバ
cnt 192.168.0.50 192.168.1.50 - コントローラ代表IP(VIP)
cnt1 192.168.0.51 192.168.1.51 - コントローラ1号機
cnt2 192.168.0.52 192.168.1.52 - コントローラ2号機
cnt3 192.168.0.53 192.168.1.53 - コントローラ3号機
nw1 - 192.168.1.61 192.168.2.61 ネットワークノード1号機
nw2 - 192.168.1.62 192.168.2.62 ネットワークノード2号機
cm1 - 192.168.1.71 192.168.2.71 コンピュートノード1号機
cm2 - 192.168.1.72 192.168.2.72 コンピュートノード2号機
nfs - 192.168.1.1 - NFSサーバ兼内部ルーター

 
DNS情報
ドメインはpikeskau.net

DNS IPアドレス
cnt.pikesaku.net 192.168.0.50
cnt1.pikesaku.net 192.168.0.51
cnt2.pikesaku.net 192.168.0.52
cnt3.pikesaku.net 192.168.0.53

 
OS
Ubuntu-16.04.3-server
 

コントローラ構築手順

 
コントローラ基本セットアップ
 
[共有サービス]
DBクラスタセットアップ
Pacemaker & Corosyncセットアップ
HAProxyセットアップ & Pacemaker組込
memcachedセットアップ
RabbitMQクラスタセットアップ
※PikeリリースからUbuntuではetcdというKVSが利用可能だが本手順では利用しない。
 
[OpenStackコンポーネント(ステートレス)]
Keystoneセットアップ
Glanceセットアップ
 

KVMネステッド環境構築メモ

参考

www.amazon.co.jp
 
 

メモ

以下2ファイルを用意
[root@localhost ~]# cat /etc/modprobe.d/kvm-intel.conf
options kvm-intel nested=1
[root@localhost ~]# cat /etc/modprobe.d/kvm-amd.conf
options kvm-amd nested=1
[root@localhost ~]#

OpenStackアーキテクチャメモ(Neutron)

機能と役割

・仮想L2ネットワークの提供
・仮想ルーターの提供
・セキュリティグループ管理
IPアドレス管理とDHCP機能の提供
 ※インスタンスIPアドレスはOpenStackに制御対象であるため、インスタンスのOS側でIPアドレスを変更すると接続できなくなる。
・外部ネットワークからのアクセスを中継
 
 

プロセス

プロセス名 説明
neutron-server REST API提供
neutron-linuxbridge-agent Linux BridgeでL2ネットワーク機能を制御
neutron-openvswitch-agent Open vSwitchでL2ネットワーク機能を制御
neutron-l3-agent L3ネットワーク機能を制御
neutron-dhcp-agent DHCP機能を制御
neutron-metadata-agent metadataサーバへのアクセスを中継
neutron-ns-metadata-proxy metadataサーバへのアクセスを中継

 
 

【neutron-server】

論理ネットワークの構成情報をDBに書き込み、メッセージングサーバ経由で構成変更をエージェントに依頼
停止しても仮想マシンの通信に影響はない。構成変更ができなくなるだけ。
 
 

【neutron-linuxbridge-agent, neutron-openvswitch-agent】

L2仮想ネットワーク機能を実現する。
現在の主流は、neutron-openvswitch-agent。

f:id:pikesaku:20171008222038p:plain

linuxbridgeにopenvswitchどちらの場合も実現することは以下。・
①同一テナント内の仮想マシン間の通信が可能
②同一テナント内の仮想マシン間の通信は物理的に異なるサーバ上に配置されていても可能
③異なるテナントの通信は、それぞれ独立し混在しない
 
上記の実現内部実装が、エージェントにより異なる
neutron-linuxbridge-agentの場合、テナント毎にブリッジ作成&VLANを分けて、異テナント間の通信の混在を避ける。
neutron-openvswitch-agentの場合、統合スイッチ(br-int)に全テナントの仮想マシンを接続しvlan & フローテーブルで異テナント間の通信の混在を避ける。
 
 

【neutron-l3-agent】

仮想ネットワークのルーティング機能。ネットワークネームスペース機能により実現
外部から接続可能なフローティングIPの割当
冗長化は他コンポーネントのように出来ない(書籍執筆時点では手法なし)
 
 

【neutron-dhcp-agent】

仮想サブネットが定義された仮想ネットワーク毎にDHCP機能を提供するdnsmasqが起動
Open vSwitchのポートに割り当てたIPアドレスをdnsmasqがListenすることで実装
DHCPだが一度割り当てられたIPは、その仮想マシンが再起動しても固定で割り当てられる。これは以下フローで実現
仮想マシン起動しdnsmasqがIP割当
②neutron-dhcp-agentが仮想マシンMACアドレス情報と割り当てたIPアドレス情報を取得し、dnsmasqに対し、固定割り当てするよう設定をする。
 
 

【neutron-metadata-agent、neutron-ns-metadata-proxy】

Novaの提供するMetadataサーバへのアクセスを補助
neutron-metadata-agentは仮想ルーター上でhttp://169.254.169.254で待ち受け、必要な情報を付加した上で、Metadataサーバに中継
neutron-ns-metadata-proxyは仮想ルーターがないNWで動作する仮想マシンが、Metadataサーバと連携するためのもの。仮想ルーターがないNWで、neutron-ns-metadata-proxyが起動してneutron-metadata-agentへのアクセスを中継する。結果、Metadataサーバと通信が可能になる。 
 

メモ

Neutron設定ポイント
①物理サーバが、どのNICを通じて外部ネットワークと接続するか?
②外部ネットワークとの接続形式(Trunk? AccessPort等)

stackoverflow.com
 
この情報より以下がわかる。
・複数の外部ネットワークを利用可能になり、以下両方が可能
 インスタンスを物理NWに直接つなげる(プロバイダNW利用)
 ユーザー定義のセルフサービスNW両方につなげる(セルフサービスNW利用)
 
Using multiple external networks in OpenStack Neutronvirtuallylg.wordpress.com
Odd Bits
http://www.marcoberube.com/archives/248
Multiple floating IP pools - OpenStack Networking Guide - current
 
上記の手法で複数の外部ネットワークを作成可能
※external_network_bridgeは空にする

OpenStackアーキテクチャメモ(Cinder)

参考

www.amazon.co.jp
 
 

機能と役割

・ブロックボリュームを管理
・Cinderが管理するストレージにブロックボリューム領域の作成・削除を実施
・作成したブロックボリュームをインスタンスに外部ストレージとして提供
・作成したボリュームにOSをインストールし、仮想マシンを起動可能(Boot from Volume) 
 
 

プロセス

プロセス構造はnovaと類似。理由は元々novaに統合されていた機能であるため。

プロセス名 説明
cinder-api CinderのREST APIを提供
cinder-scheduler ブロックボリュームを作成するストレージ装置を選択
cinder-volume ストレージ装置の操作を実施
cinder-backup ブロックボリュームのバックアップを管理

 
 

【cinder-api

APIは機能がシンプルでブロックボリューム、スナップショット、クローンの作成・削除・確認・バックアップ取得が、ほぼ全て。
停止してもインスタンスのブロックボリュームアクセスに影響なし
 
 

【cinder-scheduler】

Cinder管理のストレージの中から、どれを利用するか選択する。
nova同様にフィルターと重みで選択

フィルタ 説明
AvailabilityZoneFilter 指定されたAZに属するストレージにマッチ
CapabilitiesFilter 機能や要件の指定でマッチング
CapacityFiler 使用済み容量の割合(上限値)でマッチング

デフォルトでは空き容量が大きいストレージから利用される
 
 

【cinder-volume】

・管理対象のストレージ装置に対する実際の制御を行うプロセス
・複数ストレージの管理が可能
・停止しても仮想マシンのブロックボリュームアクセスに影響は無し
・プロセス間連携はメッセージングサーバ経由だが、並列化による冗長化はできない。
 ※理由はCinderがボリューム操作する際に、DBに操作ホスト情報を記録し、その後の操作時は、該当ホストのみがメッセージングサーバからリクエストを取り出し実行する仕様のため。
 ※複数のCinder-volumeによる同時アクセスによるブロックボリュームの破壊を防ぐ仕様(??)
 ※ボリューム操作時にDBに登録されるホスト情報は、cinder.confのhostパラメタで指定
冗長化はActive & Standbyで実装する。Active & Standby側でhostパラメタは同一の値にする
 
 

【cinder-backup】

・Cinderのバックアップ機能を提供
・Swiftにバックアップ可能
・cinder-apiがバックアップリウクエストを受付、メッセージングサーバにリクエスト格納し、cindr-backupプロセスが取り出し、バックアップを実行
 
 

処理の流れ

f:id:pikesaku:20171008175336p:plain

 

f:id:pikesaku:20171008175658p:plain

OpenStackアーキテクチャメモ(Horizon)

参考

www.amazon.co.jp
 
 

機能と役割

ダッシュボードを提供
 

プロセス

・デーモンプロセスはなし。Apache経由で動作
デバッグ用途で直接起動可能(以下コマンド)
 manage.py runserver 0.0.0.0:8000