Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年04月23日

Kayo

Pacemaker+Corosyncを使ってみました!(crmコマンド編)

みなさん、こんにちは。ピクトリンク事業部インフラ課(3月末から事業部名が変わりました)の藤本佳世です。今回は「Pacemaker+Corosyncを使ってみました!」の続編、crmコマンドを使った設定の部分についてお話しします。

前回の記事はこちら

crmコマンド集

Pacemakerの設定をしたり、確認や削除といった作業は、crmコマンドを使って行います。
今回の構築で使ったコマンドをまとめてみました。※詳しい説明は後ほど

Pacemakerの設定

crm configureコマンド使ってPacemakerの設定ができます。

この状態で1つずつ設定していくことも可能ですが、私の場合は、設定したい項目をすべてcrmファイルに書き出して、crm configure load updateコマンドを使って設定を反映させました。

setting.crmの内容はこちらです。
※仮想VIP設定は、「primitive prmVIPcheck ocf:heartbeat:VIPcheck」の部分です。
※ping疎通監視設定は、「primitive pingd_gw ocf:pacemaker:ping」の部分です。

設定内容を確認するコマンドは下記のようにshowを付けます。

また、設定を削除したいときは、eraseを最後に付けます。

ただし、ノードが「running」ステータスでは下記のようなエラーが発生します。

その場合は、全ノードを「standby」ステータスに切り替え、「running」ステータス以外にする事が必要です。

再度「online」ステータスに切り替えるには下記を実行。

そして最後に、設定のバックアップ取っておくコマンドがこちらです。

現在設定されている項目をbackup.crmに書き出してくれます。
設定をバックアップ取っておくと、再構築になった際にとても便利ですね。
backup.crmの使い方は、最初にお伝えしたように、loadするだけです。

 

今回の投稿は以上です。次回は最終版として構築ではまった部分をみなさんに共有したいと思います。


2018年03月7日

Kayo

Pacemaker+Corosyncを使ってみました!(インストール編)

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ課の藤本佳世です。
今回は、Pacemaker+Corosyncについてお話しします。
今までは、Heartbeatを使っていたのですが、サーバリプレースに伴い、最新バージョンで推奨されているPacemaker+Corosyncを構築しました。まずは、インストールの部分をお話ししたいと思います。

Pacemakerとは

オープンソースソフトウェアとして開発されている、HAクラスタソフトのこと(Heartbeat の後継)。
障害を検知したら他のサーバに自動的にフェイルオーバしてくれます。
Corosyncと組み合わせて利用します。
※HAとは、「High Availability」高可用性のこと。

Corosyncとは

ノードの死活監視を行うオープンソースソフトウェア。
Pacemakerと組み合わせて、クラスタシステムを構成します。

フリューでの利用について

主に、データベースサーバでPacemaker+Corosyncを採用しています。
サーバ(master)に仮想VIPがセカンダリIPとして割り当てられており、サーバ(master)に障害が発生した際、10秒以内(弊社環境)でサーバ(slave)に仮想VIPが付与され、masterとして稼働します。
以前のHeartbeatよりも、Corosyncの方が切替の時間が早いというメリットもあります。

構築した環境

サーバ名 OS Pacemakerバージョン Corosyncバージョン IPアドレス 仮想VIP
server1 CentOS7.4 1.1.16.1 2.4.2-1 192.168.33.28 192.168.33.21
server2 CentOS7.4 1.1.16.1 2.4.2-1 192.168.33.29

Pacemaker+Corosyncの構築

LINUX-HA JAPANのドキュメントを参考に進めました。
詳しく手順が書かれているので、この通りに進めるだけです。

インストールの後は、corosync.confを修正します。

以下のbindnetaddrとquorumの部分を修正しました。

  • bindnetaddr:構築するネットワーク環境に合わせて設定
  • expected_votes :クラスタを構成するノードの数を設定

続いて、corosync認証鍵ファイルの設定です。
どれか一つのノード上で実行します。

/etc/corosync配下にauthkey ファイルが生成されます。
作成されたauthkeyファイルをクラスタを構成する全てのノードにコピーします。

この後は、pacemakerファイルの設定です。
pacemakerの内部プロセスが故障した場合も、ノード故障として取り扱うようにするため、
以下の設定に変更します。

そして、最後にクラスタ起動スクリプトの設定です。
ドキュメントに下記の設定を反映させるために修正が必要と書かれています。

  • pacemakerサービス停止時に corosyncサービスも同時に停止させるため
  • corosyncプロセス故障時に watchdog 機能を有効にするため
  • corosyncの改善により soft_margin オプションは不要となったため

※ExecStart/Stop は置き換える前に空白にする必要があるので注意してください。

これで完了です。
ドキュメント通り進めるだけなので、簡単に構築できると思います。

いよいよ起動

設定が終わったら、いよいよ起動です。

起動確認

Onlineになっています!問題なさそうです。

ここまでがインストールの作業です。
次に、仮想VIPやping疎通監視など設定していきますが、詳細は次回説明したいと思います。
crm configureコマンドを使った設定などご紹介する予定なので、お楽しみに。


2018年02月8日

Hashimoto Naoto

ESXi6.5でOS再起動時に公開鍵が消える問題の対処方法

コンテンツ・メディア第1事業部インフラ課の橋本です。
弊社では仮想サーバをオンプレ環境で構築するための基盤(ホスト)OSとして、一部ではESXiを利用しています。

概ね便利に使えるESXiサーバには、困った特徴というか仕様がありまして、/etc 以下であるとか /bin 以下の階層に配置したファイルが、OS再起動時に初期化(クリア)されてしまいます。

接続を便利にしてくれる公開鍵なんかも、ESXiサーバを再起動するたびに消えてしまいます。

そして、以前のESXi(バージョン5.5や6.0において)で使えたいくつかの対処法は、検証した限りでは使えなくなっています。(そればかりか、再起動時にパープルスクリーンで固まってしまい、OSが起動しなくなったりさえします。なんということでしょう!)

そのため、今回ご紹介する対処方法も、これまでの方法と同様にバージョン互換性がない可能性が大いに有り得ます。具体的にはESXi6.5以外のバージョンで使えるという保障はございませんということを、ご了承いただきたく思います。

対処方法

「そもそも消されないようにする」というのが実現困難でしたので、今回は「再起動時に配置しなおす」というアプローチです。

大まかな手順はふたつです。
ひとつめ、鍵をバックアップする。
ふたつめ、再起動時に展開されるようにする。

公開鍵のバックアップをとる

以下はEXSiサーバ上での操作です。sshなどで接続します。
まずは、公開鍵ファイルをバックアップするスクリプトを用意しましょう。

13〜16行目にあたる部分で、authorized_keys をリストアップし、tarで固めています。
ここで、16行目でbin/keys-backup.sh(このスクリプト自身)をも含めているのは、このスクリプトを/binに配置しているので再起動によって容赦無く消されるためですむごい。

authorized_keysではなく、自前のスクリプトや他のファイルを保持しておきたいという場合は、この13行目〜16行目の探索条件を調整してみてくださいね。
なお、tarで圧縮する際は相対パスで指定するようにお気をつけください。
絶対パスで指定すると、展開時にも絶対パスで展開されるので、えらい目に遭うことがあります。
上記スクリプトで、わざわざ3行目に cd / の後、14行目で相対パスに直してアーカイブしているのは、そのためです。

次に、実行権限をつけておきます。

keys-backup.sh を実行すると、/bootbank/sshkeys.tgzが出来ているはずです。
念のため、アーカイブの中身を確認してみましょう。

authrized_keys 各種とkeys-backup.shがアーカイブされていれば成功です。
新しくauthrized_keysを配置したときには、併せてkeys-backup.shを実行するようにしましょう。

再起動時にアーカイブを展開させる

あと少しです。再起動時にsshkeys.tgzを展開するように仕込みを行います。

/etc/rc.local.d/local.sh はEXSi6.5ではもともと配置されているファイルです。

ファイル内に

# Note: modify at your own risk!

と記述がありますように、運用にはご注意ください。
このファイルのexit 0の前に、1, 2行目の内容を挿入しておきます。
これで、再起動が完了後に/bootbank/sshkeys.tgzが展開されるようになります。

/bin/auto-backup.sh にも似たような仕組みがもともと存在するのですが、拡張を意図されていない既存のコードはなるべく変更を加えたくないなぁ……という思いから、今回は別のスクリプトで手動実行する方式としています。


2016年11月15日

Kayo

Open vSwitchのVRRP(L3HA)で高可用性を実現する!

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。
今回もOpenStackの続き、【Open vSwitchのVRRP(L3HA)で高可用性を実現する!】についてお話しします。
前回の記事はこちら

VRRPとは

VRRP(Virtual Router Redundancy Protocol)とは、ルータの冗長化をサポートするプロトコルです。
フリューでは、OpenStackで立ち上げた仮想インスタンスに接続する際に、このVRRP機能を採用しています。
仮想インスタンスへはFloatingIPでssh接続しています。
その通信が、Neutron(networknode)サーバでプライベートIPアドレスにNAT変換され、仮想インスタンスに接続されます。この処理を行うNeutron(networknode)サーバ2台をVRRP構成にすることで、master側のサーバに障害が発生した場合、すぐにstandby側のもう1台のサーバに自動的に処理を切り替えることができます。

<イメージ図>

openstack_vrrp

構築について

公式ドキュメントを参考に構築を進めました。
ネットワークの知識が必要なので、慣れないうちは苦労するかもしれません。

サーバ構成について

コンポーネント ノード
サーバ1 Keystone/Horizon/Nova/Cinder/Glance/Neutron
※1 MySQL/Memcached/RabbitMQ
※2 Heartbeat
controllernode
サーバ2 Keystone/Horizon/Nova/Cinder/Glance/Neutron
※1 MySQL/Memcached/RabbitMQ
※2 Heartbeat
controllernode
サーバ3 Nova/Cinder/Neutron computenode/storagenode
サーバ4 Nova/Cinder/Neutron computenode/storagenode
サーバ5 Nova/Cinder/Neutron computenode/storagenode
サーバ6 Nova/Cinder/Neutron computenode/storagenode
サーバ7 Neutron networknode
サーバ8 Neutron networknode

ネットワーク作成について

ネットワーク名 ext-net80 vxlan-net80
プロジェクト admin service
ネットワーク種別 flat vxlan
外部ネットワーク external1
割り当てサブネット ext-subnet80
10.0.80.0/24
vxlan-subnet80
192.168.80.0/24
Gateway 10.0.80.1 192.168.80.1

※1ネットワークセグメントのみの情報です。実際には同じような構成で3パターン作成しました。

設定内容

各ノードに対して設定を行います。ポイントとなる部分を書き出してみました。

用語の説明

NAT変換 IPアドレスを変換する技術のこと
VXLAN L3ネットワーク上に論理的なL2ネットワークを構築するトンネリングプロトコルのこと
ML2プラグイン OpenStack Networking で、複雑な実世界のデータセンターで使われている様々な L2 ネットワーク技術を同時に利用できるようにするフレームワークのこと
GRE ML2 がサポートするネットワークセグメントタイプの一種
Flat ML2 がサポートするネットワークセグメントタイプの一種
DHCP IPアドレスなどを自動的に割り当てる仕組みのこと

controllernode

共通のオプションを設定します。

ML2プラグインを設定します。

networknode

Open vSwitchエージェントを設定します。

L3エージェントの設定します。

DHCPエージェントを設定します。

メタデータエージェントの設定します。

computenode

Open vSwitchエージェントを設定します。

ネットワークの作成

次は、ネットワークの作成の手順をご紹介します。
フリューでは、3つのネットワークセグメントが存在し、それぞれ仮想ルータを3台構築しました。

下記の通り、flat外部ネットワークとプロジェクトネットワーク(vxlan)を作成しました。

ネットワーク名 ext-net80 vxlan-net80
プロジェクト admin service
ネットワーク種別 flat vxlan
外部ネットワーク external1
割り当てサブネット ext-subnet80
10.0.80.0/24
vxlan-subnet80
192.168.80.0/24
Gateway 10.0.80.1 192.168.80.1

※1ネットワークセグメントのみの情報です。実際には同じような構成で3パターン作成しました。

flat外部ネットワーク作成

  1. 外部ネットワークを作成 ※下記の例では「ext-net80」というネットワーク名で作成しました。
  2. 外部ネットワークのサブネットを作成

プロジェクトネットワーク(vxlan)作成

  1. serviceプロジェクトのidを取得
    ※ここではすでにserviceプロジェクトが存在することを前提としています。
  2. ネットワーク作成
    ※先ほどとは異なり、network_typeにvxlanを指定します。
  3. サブネットを作成
  4. 仮想ルータの作成
  5. サブネットを仮想ルータにインターフェースとして接続
  6. ルータに外部ネットワークへのゲートウェイを追加

HA確認

  1. 下記のコマンドでVRRP(active,standby)構成になっていることが確認できます。
  2. networknodeで、qrouterとqdhcp名前空間の作成を検証します。
    ※両方のqrouter名前空間で同じUUIDが使われているはずです。

  3. networknodeでHAの動作確認をします。
    ※qrouter 名前空間には ha, qr, qg インターフェースがあります。バックアップノードはqrとqgインターフェースはIPアドレスを持ちません。

    ha インターフェース 169.254.192.0/18 の範囲の一意な IP アドレスを持つ
    qr インターフェース プロジェクトネットワークのゲートウェイ IP アドレスを持つ
    qg インターフェース 外部ネットワーク上のプロジェクトルーターの IP アドレスを持つ

  4. Networknodeで、マスターノードの HA インターフェースの IP アドレスから VRRP 通信が行われていることを確認します。

冗長化することは、どんなシステムでも重要視される部分ですね。

最後に

今回初めてVRRPという単語を聞いた私にとっては、かなり苦戦する部分ではありましたが、何とか構築することができました。ネットワーク知識が必要となりますが、少しでも構築の参考になれば嬉しいです。


2016年08月23日

Kayo

7つのOpenStackコンポーネントと構築手順

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。今回は、OpenStackの続きで、7つのコンポーネントとノードの役割、構築手順についてお話しします。

7つのコンポーネントとノードの役割

前々回の記事でも少し触れましたが、OpenStackは7つの機能から構成されます。
注意:OpenStackのバージョンアップに伴い、コンポーネントの数も更新されます。実際には、16のコンポーネントが存在しますが、今回は、構築で重要となる7つについてお話ししたいと思います。

コンポーネント 役割
Nova 仮想マシンの提供と管理を行う
Keystone ユーザー認証・管理を行う
Horizon Webブラウザ経由で管理・操作できるGUIコンソールを提供する
Glance 仮想イメージの管理を行う
Cinder 仮想マシンが使用するストレージ管理を行う
Neutron 仮想ネットワークの管理を行う
Swift クラウドストレージを提供する

役割ノードの紹介

ノードタイプ 役割
controllernode OpenStack 環境が機能するために必要な管理ソフトウェアサービスを実行
computenode OpenStack 内の仮想マシンインスタンスを実行
storagenode OpenStack環境に必要な全データを保管
networknode Openstack環境に必要なすべての仮想ネットワーキングを実行

各コンポーネントとノードの紐づけ

各コンポーネントごとのノードの役割を下記の図で表しています。

Nova controllernode computenode
Keystone controllernode
Horizon controllernode
Glance controllernode
Cinder controllernode storagenode
Neutron controllernode computenode networknode

構築にあたって

7つのコンポーネントをどのサーバノードで稼働、同居させるかは、負荷分散や冗長化の観点から、とても大切な設計です。みなさんもご自身の環境、サーバスペックにあった構成を組んでいただければと思いますが、フリューでは、サーバ8台構成でOpenStackを構築しました。また、今まではCentOSを使うことが多かったのですが、OpenStackでは、Ubuntu14.04LTSをホストOSとして採用しました。

理由

  1. Ubuntuは標準パッケージでOpenStack環境が用意されている。
  2. Ubuntu/debianの基本方針として、ディストリビューションのバージョンが変更されない限り、パッケージのバージョンは更新しない方針なので、不意にOpenStack環境がバージョンアップされない。 ※Firefoxなど例外あり
  3. LTSを使用すれば、2年または4年毎くらいでディストリビューションのバージョンアップが可能。 ※サポート期間は5年

(さらに…)