edubase Cloud(Eucalyptus)とは

羽深 修

@habuka036

NTTデータ先端技術株式会社

Japan Eucalyptus Users Group

2012/10/26

自己紹介

●どうやらEucalyptus Users Group Japanのチェアマンらしいです

◇Eucalyptusの本を出してます

◇クラウド Watch で連載しています

Eucalyptusって何？

Eucalyptusの概要

●Amazon EC2/S3互換のプライベートクラウド環境(IaaS環境)を構築できるOSS ◇“互換”ではあるが、プライベートクラウドでは必須でない機能は実装していない

◇ライセンスはGPLv3 ◇カリフォルニア大学サンタバーバラ校のコンピュータサイエンス学科の研究プロジェクトとして開発がスタートし、現在はEucalyptus Systems, Incが開発

◇現在のバージョンは3.1.1 ◆ 2012年中に3.2が出る予定

●Linuxで動きます ◇ GuestOSは今のところLinuxとWindows

◆ FreeBSDとかも…

◇ハイパーバイザ ◆ Xen,KVM,VMware(vSphere, ESXi)

Eucalyptusの核となる機能

仮想マシンに取り付け可能な仮想ディスクを提供する「EBS機能」

仮想マシンの起動停止を管理する「インスタ

ンス機能」

仮想マシンイメージの管理やAmazon S3互換の大規模ストレージ機能を提供

する「S3機能」

ファイアウォールの機能を提供する「セキュリティグループ機能」と取り付け取り外しが可能な

PublicIPを提供する「ElasticIP機能」

それ以外のEucalyptusの主な機能

●Eucalyptus版IAM ◇AWSのIAM互換なアカウント管理システム

●EBSインスタンス ◇従来のS3インスタンスと違い、インスタンスを停止してもデータが消えないインスタンス

●高可用性(HA) ◇CLC,CC,SC,Walrus(NCとVMware Brokerを除く)の各コンポーネントを冗長構成にして、コンポーネントが落ちた際にフェイルオーバー

●AD/LDAP連携 ◇AD/LDAPと連携してアカウント管理

歴史

2012/06/27

3.1をリリース

Eucalyptusの コンポーネント

コンポーネントの全体図

フロントエンド

●Frontendは、主にユーザからの要求を受け付ける機能を持つコンポーネントの集合

●そのため、CLC, CC, Walrusはユーザからアクセス可能なネットワークに配置されなければならない

●SCは直接はユーザと通信しないが、クラスタ毎に配置が必要なので、CCと同居させる構成がよく見られる ◇ただし負荷によってはCCと別居構成にする

ゾーン

●Zoneは、Nodeとそれらを管理するクラスタコントローラとそのZoneに所属するストレージコントローラの集合です

●マルチクラスタ構成が可能になったv1.6系からはクラスタ毎にストレージコントローラを配置する構成が標準になりました

●v2.0系では、アーキテクチャ的な仕様により、ストレージコントローラはクラウドコントローラと通信可能なネットワークに所属していなければなりません

ノード

●Nodeはその名のとおりノードの集合体

●1つのゾーン内のノードで使用できるハイパーバイザーは1種類のみ ◇指定したマシンイメージがどのノード(物理マシン)上で起動するかを指定できないため

◇XenでもKVMでも起動するカーネル、RAMディスク、イメージを作れば混在してても大丈夫かもしれないが…メリットがあまり無い

クラウドコントローラ

●クラウドコントローラ(CLC)には主に以下の役割があります

◇ユーザアカウントの管理や認証

◇ユーザの要求を受け付ける

◇受け付けた要求をクラスタコントローラ(CC)に渡す

◇設定値やクラウド内の情報をDBに格納し管理

◇Web管理画面の提供

◇v3.x系からはLDAP/AD連携機能が追加

クラスタコントローラ

●クラスタコントローラ(CC)には主に以下の役割があります

◇CLCからの要求を受けノードコントローラ(NC)に処理を要求する

◇NCで起動しているインスタンスのネットワークを制御

◇ユーザがインスタンスに接続する際のPublicIPの提供

◇NCの空きリソースを監視

◇v3.xからはマシンイメージをキャッシュする機能が追加

ノードコントローラ

●ノードコントローラ(NC)には主に以下の役割があります

◇CCからの要求を受け、Walrusからマシンイメージを取得

◇マシンイメージをキャッシュ

◇インスタンスの起動や停止、EBSボリュームの取り付けや取り外しなどの処理をハイパーバイザー(XenおよびKVM)に依頼

ストレージコントローラ

●ストレージコントローラ(SC)には主に以下の役割があります

◇ボリュームの管理

◇ボリュームからのスナップショットの管理

◇インスタンスに対するボリュームの提供

◇v3.x系からは外部ストレージ(SAN/NAS)に対してボリューム操作が可能

Walrus/VMware Broker

●Walrus

◇Walrusには主に以下の役割があります

◆ S3互換の大規模ストレージ

◆マシンイメージの管理および提供

●VMware Broker

◇VMware BrokerはESXi上でインスタンスを起動するためのコンポーネントであり、CCからの要求をvCenterに渡す役割を担う

ネットワークモード

ネットワークモードについて -1-

● Eucalyptusには4つのネットワークモードがあります ◇ SYSTEMモード、STATICモード、MANAGEDモード、MANAGED-NOVLANモード

● SYSTEMモード ◇ SYSTEMモードはEucalyptusを1台のマシン上で動作させることができるた

め、手軽にEucalyptus環境を構築することが可能

◇ Elastic IPやセキュリティグループといった機能を利用することができない

◇ 別途DHCPサーバを自前で構築する必要あり

◇ Eucalyptusクラウドとして独立したネットワークを構成するわけではなく、既存システムと同一ネットワーク上にインスタンスが配置される

● STATICモード ◇ STATICモードはMACアドレスとIPアドレスを予め設定しておきインスタンス

に割り当てる方式

◇ 各インスタンス毎にひとつのIPアドレスのみを持つこととなり、Elastic IPの機能を利用することはできない

◇ それぞれのインスタンスはフラットなネットワークを構築し、各セキュリティグループごとに分離されたネットワークに配置することができない

ネットワークモードについて -2-

●MANAGEDモード ◇ MANAGEDモードではEucalyptusが提供する機能をフルで利用できる

◇各インスタンスはセキュリティグループごとに別々のセグメントに配置され、Elastic IPの機能によってパブリックIPを割り当てることができる

◇ CCとNCを繋ぐスイッチにインテリジェンスなスイッチを利用している場合、適切にスイッチを設定しないと──タグVLANが通るように適切に設定しないとEucalyptusが動作しなく、ハマる原因になる

●MANAGED-NOVLANモード ◇ MANAGED-NOVLANモードはMANAGEDモードと違いタグVLANを使用しない

◇セキュリティグループごとにセグメントは分離されません。しかしそれ以外はMANAGEDモードと同じように利用できます。

ネットワークモードについて -3-

●各ネットワークモードの機能比較

･ *1 Eucalyptusの管理外のDHCPサーバは利用できます。

◇VLANは、インスタンス同士の通信網をVLANを使って論理的に分離するかどうかを表します

◇メタデータは起動したインスタンスから自分自身の情報(インスタンスIDやインスタンスタイプなど)を取得する機能が利用できるかどうかを表します

ネットワークモード/機能

Elastic Ip管理 DHCPセキュリティグループ管理

VLAN メタデータ

SYSTEM × - *1 × × ×

STATIC × × × × ×

MANAGED ○ ○ ○ ○ ○

MANAGED-

NOVLAN○ ○ ○ × ○

動作に必要な環境

CLCを動かすために

●CPU ◇ CPUはさほど高速である必要はない ◇ただし最低でも2GHz程度でコア数は2コアは必要 ◇ユーザからのAPIをさばける程度でOK

●メモリ ◇メモリ容量はJavaのプロセスが動くため少なくとも4GB以上必要

●ディスク ◇ディスク容量や性能はほとんど必要としない

●NIC ◇ NICの枚数は1枚あれば十分 ◇もちろん、bonding構成であればより望ましい ◇ NICのスペックは1Gであれば足りる ◇ HA構成を構築する場合は、追加でもう1枚あったほうがいい

CCを動かすために

●CPU ◇ NCへの通信を処理するためにある程度の性能は必要だが、

Xeonクラスの3GHz以上であれば十分

●メモリ ◇メモリもある程度あると安心 ◇ 8GB程度あれば十分

●ディスク ◇ CLC同様にディスクはほとんど使わない ◇ただし、マシンイメージのキャッシュ機能を有効にする場合にはそれなりに必要

●NIC ◇ NCへの通信を処理するため、1G以上、10Gあると安心 ◇もしくは1G数本でbonding構成 ◇基本的にCCのNICは2枚構成がスタンダードおよび最小値 ◇ HA構成を構築する場合は更に追加でNIC1枚が必要

NCを動かすために

● CPU ◇ ある程度の集約性は欲しいので、コア数は8コア以上

◇ VT機能はあったほうがよい

◇ 特にWindowsなどをゲストOSとして利用する場合

● メモリ ◇ メモリもある程度あると安心

◇ 最低でも8GB以上は必要

● ディスク ◇ VM Typesの設定値にもよるが、ある程度のディスク容量は必要

◇ 最低でも500GB～1TBが望ましい

◇ マシンイメージのコピー処理が多いため、ディスクの回転数自体も高速なものが望ましい

● NIC ◇ インスタンスによってネットワークの利用率が異なるため、一概に

10G必須とは言えないが、1Gは必須

SCを動かすために

●CPU ◇特にCPUに要求はないが、I/Oの性能が低下しない程度のスペックは必要

●メモリ ◇ CPU同様に要求はないが、EBSの利用が多い場合にI/Oの性能低下が発生しない程度の容量は必要

●ディスク ◇ EBS機能の利用が多い場合にはディスクは市販ストレージにしたほうが望ましい

◇もちろん、容量/性能どちらも優れているほうが良い

●NIC ◇ NC側──つまりバックエンド側で使用するNICは10Gのほうが望ましい

◇もちろん1G複数でbondingでも可

Walrusを動かすために

● CPU ◇ 特にCPUに要求はないが、I/Oの性能が低下しない程度のスペックは

必要

◇ マシンイメージの登録時にはCPUパワーが要求される

● メモリ ◇ CPU同様に要求はないが、Walrusをマシンイメージの管理のみなら

ずオブジェクトストアとして利用する場合にはI/Oの性能低下が発生しない程度の容量は必要

●ディスク ◇ 利用度にもよるが、外部ストレージを利用するようにしたほうが、

ディスク容量が少なくなった場合に対応できるので良い

◇ もちろん、容量/性能どちらも優れているほうが良い

● NIC ◇ NC側──つまりマシンイメージを提供する側のNICは10Gのほうが望

ましい

◇ もちろん1G複数でbondingでも可

その他必要スペック

●ネットワーク機器に要求されること ◇EucalyptusのネットワークモードをMANAGEDに設定する場合は、CCとNCを接続するスイッチにインテリジェンスなスイッチを用意すべき

◇バックエンド側のNICでもbonding設定を使用する場合には、それなりのポート数を保有するスイッチが必要

●ディスク容量の最小値 コンポーネント ディレクトリ 最小値 (GB)

CLC /var/lib/eucalyptus/db 20

CLC /var/log/eucalyptus 2

Walrus /var/lib/eucalyptus/bukkits 250

Walrus /var/log/eucalyptus 2

SC /var/lib/eucalyptus/volumes 250

CC /var/lib/eucalyptus/CC 5

CC /var/log/eucalyptus 2

NC /var/lib/eucalyptus/instances 250

NC /var/log/eucalyptus 2

構成例 -1-

● マルチクラスタ構成 ◇ Walrus、SCは外部ストレージを使用せず、自身のストレージを利用する構

成

◇ CLC、Walrus、CCはユーザから到達可能な場所へ配置すること

◇ SCはユーザから到達可能である必要はないが、CLCとは通信が可能な場所に配置すること ◆ EBSのスナップショット機能はWalrus上にスナップショットイメージをアップロード

するため、Walrusとも通信可能であることが望ましい

◇ CC、SCはNCと通信可能な場所へ配置すること

CLC

CC CC SCSC

NC NC NC NC

Walrus

構成例 -2-

● HA構成 ◇ SC、Walrusのストレージはそれぞれ外部ストレージを使用する

◇ CLCでのユーザ認証はLDAP/AD連携を使用する

◇ CLC、CC、SC、Walrusは各2台づつ用意し、Active/Standby構成とする ◆ 図中にて明記していないが、この4コンポーネントは死活監視用のNICおよびネット

ワークが必要

◆ 同じく明記していないが、Standby側も 正常系のネットワークに接続すること

◇ LDAP/ADはCLCと通信可能とする

◇ Walrus用の外部ストレージはWalrusと通信可能なこと

◇ SC用の外部ストレージはSCおよびNCと通信可能なこと

NC NCNC NC

SC SCCC CC

CLCWalrus

SANNAS

SANNAS

SANNAS

AD/LDAP

コミュニティの宣伝

日本のコミュニティ活動

●コミュニティ ≠ 羽深 ●前佛さんに無理言って、JEUGのサイトをリニューアルしてもらいました ◇ただし、人手が足らず更新がなかなか情報発信できず…

●勉強会は今年度には開催したいです...

利用事例

国内

●GMOインターネット株式会社が運営するとくとくショップにてHadoopやCassandraを動かす基盤として利用 ◇2010-04頃の情報ではv1.6.1を利用

●国立情報学研究所のGRACEセンターが、先導的ITスペシャリストの育成を行なう際に、学生が自由にアイデアを試せるIT実験室として、Eucalyptusをベースとしたedubase Cloudを学生に提供 ◇2011-11現在、v1.6.2と一部v2.0の機能を取り込んだものを利用

海外

● PUMAがwww.puma.comや子会社やイベント用サイトをEucalyptusで運用しだす

◇今まで子会社やイベント用のWebサイトはそれぞれで構築運用を行なっていた

◇コスト的にも非効率であったため、Eucalyptusで運用することにより、急にWebサイトが必要になった場合にも迅速に対応できるようになった

●ソーシャルゲームのプロバイダ「Plinga」がAmazon EC2で稼動させていたシステムをEucalyptusに移行しだす

◇マシンイメージやEC2 APIがそのまま利用できる点にメリットを感じたとのこと

●インドのNational Informatics Centre(国立情報学センタがEucalyptus上で電子政府プロジェクトを開始

◇2009年にハイデラバードで1クラウドを稼動させ、現在ではインド各地で10クラウドを稼動させ、停電や不測の事態が発生しても公共サービスなどが利用できるように計画中

dodai project

dodai projectって何？

●dodai projectとはNIIを中心としたコミュニティ活動の中で作成された以下のプロダクトをオープンソースとして開発/運用するプロジェクトです

◇dodai-deploy

◆複数台のマシン上にOpenStackやHadoopなどのミドルウェアを簡単にインストールするためのツール

◇dodai-compute

◆複数の物理マシンにOSをインストールするためのツール

CaaSとは？

●CaaSとはCluster as a Serviceの略で、以下のような要望を叶えるためにPCクラスタをサービスとして提供する技術を開発するプロジェクトです。(http://wiki.openstack.org/CaaS) ◇仮想化環境ではなく物理環境を直接利用したい

◇複数台のマシンに対してOSやミドルウェアを手間なくインストールしたい

◇IaaS環境やPaaS環境を色々な構成で構築したい

PC クラスタ

SaaS基盤

PaaS基盤

IaaS基盤 CaaSで提供

「dodai」の名前の由来

某機動戦士に出てくる青いアレがムチを振りながら踏んづけている赤いアレが名前の由来だそうです

キーパーソン

●主にアイデアを出している人

●主に実装している人

@guanxiaohua2k6 さん

@jxta さん

dodai-deployについて

これは何？

● 簡単に言うと「複数マシンにソフトウェアをインストールしてくれるツール」です

● リポジトリや情報は以下にあります ◇ https://github.com/nii-cloud/dodai-deploy

● 使い方はOpenStackの管理者マニュアルにも書いてあります。 ◇ http://docs.openstack.org/essex/openstack-

compute/admin/content/openstack-compute-deployment-tool-with-puppet.html

● 主にrailsとpuppetとmcollectiveを使ってます

● dodai-deployは以下のコンポーネントで構成されます ◇ サーバ

◆ インストールするソフトウェアの設定や構成を管理

◆ インストール対象のマシン情報を管理

◆ ノードに指示を出す

◇ ノード ◆ インストール対象の各マシン上に配置

◆ サーバからの指示に従ってインストール/アンインストールなどを行なう

● 利用者は、Web UI/CUI/REST APIから好きな方法で利用可能

発端はDeployment Tool

● 反復作業は嫌。やっぱDRYだよね。 ◇ OpenStackを様々な構成や設定で何度も何度もインストールする日々がツラ

いので、何とか簡単に環境を作れないものだろうか？というのが最初の要求

● bashで書いてみた ◇ OpenStackのインストール省力化が目的なのに、そのためのアプリケーショ

ンやツールやライブラリを頑張ってインストールしなきゃいけないのはナンセンス

◇ しかし、この時点ではまだこのツール自体のセットアップに手数を要する

● pythonで書き直した ◇ bashで何とか頑張ってみたけど生産性を向上させるのがツラいのでpython

で書き直した

◇ それでもこのツール自体のセットアップに手数を要する状態はなかなか解消できなかった ◆ 最初の要求であるOpenStack環境の構築が省力化できるようになることがmustだった

ので…

◇ ちなみに以下にデモムービーがあります ◆ http://wiki.openstack.org/NovaInstall/NovaDeploymentTool#Deployment_Tool_for

_Cactus

● そしてrubyになってdodai-deployとして再出発

CrowbarやJujuがあるのに？

●"自分らで作りたかった"

●Deployment Toolを作ってた頃はEnsembleすら無かった(はず…)

●Crowbarは作られ始めてたがdodai-deployとしては既にOSがインストール済みである環境でも利用できる必要があった

●どっちにしてもそれらはまだ開発中だった

●将来的にはUbuntuだけじゃなくCentOSもターゲットにしたかった

何がデプロイできるの？

●対応しているOSは2012/09/08時点で2つ ◇Ubuntu 10.10/11.04/11.10/12.04 ◇CentOS 6.x

●デプロイできるソフトウェアは以下 ubuntu

10.10 ubuntu 11.04

ubuntu 11.10

ubuntu 12.04

CentOS 6.x

OpenStack Essex (Nova, Glance, Swift, Keystone)

✔ △※

OpenStack Diablo (Nova, Glance, Swift)

✔ ✔ ✔

Eucalyptus 3.1 △※

hadoop 0.20.2 ✔ ✔ ✔ ✔

sun grid engine 6.2u5 ✔ ✔ ✔

※ まだ開発版でのみ

今後の野望とInstall as a Service

●今後、以下を予定

◇Folsomサポート

◇ソフトウェア定義ファイルテンプレートの再検討

◇ソフトウェア定義ファイルテンプレートのダウンロードとアップロード

◇サポートするソフトウェアを増やす

◇マルチテナント化

◇Install as a Service

◆アプリケーションのインストールを楽にしたいのだから、デプロイメントツールのインストールなんてもっと簡単じゃないと嫌だよね

◆だったらサービスとして提供すればいいんじゃない？

dodai-computeについて

これは何？

●簡単に言うと「物理マシンにOSをインストールしてくれるツール」です

●リポジトリや情報は以下にあります ◇https://github.com/nii-cloud/dodai-compute

●主にOpenStackを使ってます

●dodai-computeには以下の機能があります ◇物理マシンの電源ON/OFF/リブート

◇リソースプール

◇物理マシンへのマシンイメージの適用

◇ディスク消去

◇物理マシンのネットワーク設定

どうしてベアメタル？

●「IaaS環境を自由自在な構成で楽に作成できる環境が欲しかった」

◇「別に仮想化の上でもIaaS作れるでしょ？」

◇「全てのIaaS基盤がIaaSの上に作れるわけじゃない」

CrowbarやMAASがあるのに？

●Ubuntu以外のOSも使いたい

●ネットワーク構成をPCクラスタ毎に隔離したい

●将来的には物理マシンも仮想マシンも同じく扱えるようにしたい

◇せっかくOpenStackを流用しているので

現状と今後の野望

●現状はオープンソースで公開しているとは言え、dodai-computeの環境を構築するためには色々と他にも必要なものがある ◇OpenFlow

◇os-duper (CentOS 6.2のLiveDVD)

●現状は一部のEC2 APIのパラメータを拡張してしまったので、次のバージョンでは拡張しない作りにする予定

●現バージョンでは少しだけCobblerを使ってるけど有効活用していないので、次のバージョンでは役割を再検討する

dodaiの利用事例

アラバマ大学での利用事例

●概要

◇dodai-deployを使って彼らのHPCクラスタ「Gibson」にessexを入れてみたらしい

●構成

◇Head Node ×1

◇Image Server ×1

◇Compute Node ×3

●詳しくは以下のURLに書いてます

◇http://cloud.cs.ua.edu/wiki/index.php/Openstack_Essex

NIIでの利用事例

●研究者や学生向けにIaaS基盤やPaaS基盤を構築する環境としてdodai-computeとdodai-deploy(とOpenFlow{Switch,Controller}と

SwiftとNFSサーバとWebUI)を組み合わせて利用

NIIでの利用事例

● TopSEの講義にて学生に対してクラウド基盤の構築演習を行なう環境として利用中 ◇ 物理マシンには「仮想化の入

れ子 (Nested KVM)」が提供できるOSをインストール

◇ 物理マシンの KVM 上で CentOS 6.2 を稼動

◇ 学生は CentOS 6.2 の上でクラウド基盤(Eucalyptus)を構築する演習を実施

やっべ、 ユーカリ最高！

参考資料

参考情報 ～1～

●Eucalyptus Systems, Inc. ◇http://www.eucalyptus.com

●オープンソース版のサイト ◇http://open.eucalyptus.com

●日本 Eucalyptus ユーザ会 ◇http://eucalyptus-users.jp

●日本 Eucalyptus ユーザ会の ML ◇http://ml.eucalyptus-

users.jp/mailman/listinfo/eucalyptus-users ◆気軽に質問してください

●Twitter ◇@eucalyptuscloud ◇@jEucalyptusUG

参考情報 ～2～

●Eucalyptusではじめるプライベートクラウド構築 ◇ http://www.impressjapan.jp/books/3025 ◇正誤表 http://bit.ly/qvGZAP

●ユーカリプタス入門 (クラウドWatchで連載中) ◇日本語版

http://cloud.watch.impress.co.jp/docs/column/eucalyptus ◇英訳版 http://bit.ly/qr4gFH

●データセンター完全ガイド 2011年 冬号 ◇ http://t.co/5UFCdN0

●tAWS Tanacasino (利用者用GUIクライアント) ◇ http://sourceforge.jp/projects/eclipse-aws/

◆ Amazon EC2やOpenStackでも使えます

●マシンイメージ工房 ◇ http://eucalyptus.machine-image.com/

参考情報 ～3～

●dodai project ◇https://github.com/nii-cloud/dodai

●タイトルとか ◇しねきゃぷしょん

◇http://chiphead.jp/font/htm/cinecaption.htm

●本文とか ◇ゆたぽん(コーディング)

◇http://net2.system.to/pc/font.html

●箇条書きの記号 ◇こくばん

◇http://falseorfont.web.fc2.com