Furyu

[フリュー公式] Tech Blog

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

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年

(さらに…)


2016年06月27日

Kayo

Ansible Meetup in Tokyo 2016.06に行ってきました!

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。前回のブログの続き、「OpenStack構築手順」などご紹介する予定ですが、その前に2016年6月1日(水)に開催された「Ansible Meetup in Tokyo 2016.06」に参加したお話しをしたいと思います。自称「Ansible女子」の私。3年前にも参加したことがあり、今回は3回目の参加でした。

詳細URL http://ansible-users.connpass.com/event/31222/

Ansible

Ansibleとは、今回Meetupの会場でもあるレッドハットが開発するオープンソースの構成管理自動化ツールです。
ssh通信を利用して、クライアントサーバに直接命令を送り込むことができます。
フリューでは約3年前にAnsibleを導入し、ミドルウェアのインストールなどサーバ構築・管理には欠かせないツールとして利用しています。Ansibleを使うメリットはとても大きく、導入したことで、今まで手動で3時間もかかっていたサーバ構築作業を、1時間以内まで時間短縮を実現することができました。
使い始めた頃は、参考書も少なく、公式HPの英語ドキュメントを参考にしていましたが、今年の4月にO’Reillyから本も発売され、ますます注目されています。

公式ホームページ https://www.ansible.com/

発表内容

  • 「Ansible Core 2.0 Overview and future releases」 by Dylan Siliva
  • 「Jupyter+AnsibleによるLiterate Computing(手順書 as a Code)への挑戦」 @ enakai00
  • 「共通言語Ansible」 @seri_wb
<LT詳細>
  • 「ansible-vaultについて何か」 (ynn)
  • 「Ansibleの教育トレーニングはじめました」 (spchildren)
  • 「Ansible2.0とOpenStackの関係」 (saito_hideki)
  • 「Playbookからのドキュメント自動生成やってみてる」 (h-hirokawa)
  • 「Ansibleとterraformで実現するタグベース複数環境プロビジョニング実例」 (takuya_onda_3)

内容まとめ

Ansible2.0新機能と今後のリリース関連

  1. 200以上の新しいモジュールが追加された
  2. エラーメッセージの改善:よりわかりやすくエラーメッセージ内容を記載するようになった
  3. アーキテクチャが変更され、より簡単に開発できるようになった
  4. ansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールがリリースされた
  5. 36個の OpenStackモジュール追加され、バージョン1と比べて、とても使いやすく親和性が高い
  6. sudo機能が使えなくなる予定。ansible_ssh_hostnameを ansible_hostname, ansible_userに変更する必要がある
  7. 約400以上のモジュールをリリース予定(Dockerモジュールも追加予定)
  8. python3対応予定
  9. クラウド技術にも力を入れる予定 (AWS, OpenStackなど)

運用について

  1. 開発とインフラの作業ラグをなくす取り組みについて、ミドルウェアバージョンアップなどインフラではなく、開発メンバーにAnsibleを実行してもらっている
  2. ansible-vaultと呼ばれる機密情報が書かれたファイルを暗号化するツールの利用
  3. Ansibleは自動化だが、やはりメンテナンスする必要がある。複雑なplaybookを書いてしまい、結果ブラックボックス化してしまう。手順書を用いることで、だれが見ても分かるようにする
  4. Ansibleコードをシンプルに保つことが大切

感想

Ansibleバージョン2.0の新機能や今後リリース予定のモジュールなどの紹介がありました。
個人的には、【Jupyter+AnsibleによるLiterate Computing(手順書 as a Code)への挑戦 @ enakai00 】の発表が非常に興味深かったです。手順書作成の必要性について、いかにAnsible(コード)だけに頼らず、うまく手順書にAnsibleを載せるかについて紹介されていました。

私が所属するインフラチームは、Ansibleを導入して約3年ほど経ちます。新規サーバ構築以外に、ミドルウェアのアップデート、脆弱性対応など、様々なケースで利用しています。しかし、Ansibleの構成が複雑化してしまい、他のメンバーが使いこなす事が非常に難しい状態です。そんな時、やはり手順書があればと思っていました。発表で「Jupyter」を使った手順書作成についてのお話しを聞くことができました。Jupyterの知識はゼロですが、是非検証してみたいなと思いました。

その他にもOpenStackについて、Ansibleバージョン2以降、とても使いやすくなったとの発表もありました。
前回のブログで紹介したOpenStackは、Ansibleを使って構築しました。今後のブログで、その手順をご紹介するので、是非読んでいただければ嬉しいです。


2016年03月30日

Kayo

OSインストールの自動化

自己紹介

Furyu Tech Blogを読んで下さっているみなさん、初めまして。 コンテンツ・メディア第1事業部のインフラチームに所属していると藤本佳世と申します。今回が初投稿となりますが、これからみなさんに「フリューのインフラ技術」をご紹介できればと思っています。 どうぞよろしくお願い致します。

インフラの仕事

インフラの仕事は、サーバの選定から始まり、OS・ミドルウェアのインストールや監視など様々な仕事があります。 開発メンバーがスムーズに仕事をこなせるよう、日々「縁の下の力持ち」として頑張っています。 今回は、インフラ業務の中でも、「OSインストールの自動化」について、お話したいと思います。

PXEブート

みなさん、「PXEブート」はご存知ですか?

(さらに…)