OpenStack base public cloud service by GMO Internet Inc., at 2013/12/12 Okinawa Open Days 2013

OpenSackを採用したパブリッククラウドサービスのご紹介 ~ Engineering SIDE ~

1

OpenStackを採用したパブリッククラウドサービスのご紹介 ~ Engineering SIDE ~

Okinawa Open Days 2013 ; 2013/12/12

GMOインターネット株式会社システム本部　サービス開発部システムインテグレーションチーム　郷古　直仁


2

まずは自己紹介

• 郷古　直仁 (ゴウコ　ナオト, Naoto Gohko) – Twitter: @naoto_gohko – Facebook: http://www.facebook.com/gohko

• 所属: GMOインターネット株式会社 • 部署: システム本部サービス開発部システムインテグレーションチーム • なにをしているのか: GMOグループ内のSI-er的な感じのチーム • 関わっているもの:

– Bekkoame INTERNET, 3WEB, 社内webとmail, その他 • お名前.com web系システムなど

– お名前.com VPS VZ(Virtuozzo) ; インフラとか – GMOアプリクラウド ; インフラとか – お名前.com VPS KVM(OpenStack Diablo環境) ; インフラとか – ConoHa VPS(OpenStack Grizzly環境) ; インフラとか


3

アジェンダ• ◎OpenStackのシステム構成

‒ OpenStackを選択する理由 ‒ GMOインターネット仮想化のサービス ‒ OpenStack Diablo ‒ OpenStack Grizzly

• ◎独自カスタマイズの概要 ‒ shutoff (ACPI shutdown) ‒ GMO API (VirtIO on/off, ISO boot, snapshot, serial console) ‒ IPv4/IPv6 DualStack DHCP agent構成 (Grizzly) ‒ Quantum periodic_interval, MariaDB

• ◎OpenStack以外に利用しているOSS ‒ serial console: (anyterm, nova-console, conserver, collectd)

• ◎今後の課題 • ◎まとめ


4

◎OpenStackのシステム構成; OpenStackを選択する理由OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?

・OpenStackはオープンソースであり、だれでも利用したり開発に参加したりできる =>> http://www.openstack.org/

http://www.openstack.org/


5

OpenStackのシステム構成; OpenStackを選択する理由OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?

・Pythonで書いてあるので、実働するソースが可読しやすい


6


・Computeの仮想化対応が「マルチHypervisor対応」である完全仮想化型: VMWare vSphere(ESXi), Xen(libvirt, XenServer), KVM, Qemu(without vt-x), IBM PowerVM, Hyper-V コンテナ型: LXC via libvirt, Docker 仮想化システム型: VMWare vCenter ベアメタルサーバー型: (Intel, ARM)(with IPMI or other Manage)

・http://wiki.openstack.org/wiki/HypervisorSupportMatrix

http://wiki.openstack.org/wiki/HypervisorSupportMatrix

https://github.com/openstack/nova/tree/master/nova/virt












































7


・Neutronによりネットワーク構成モデルの自由度が高い(Flat, VLAN, SDN) 例) http://docs.openstack.org/network-admin/admin/content/use_cases.html

Shared Network10.0.0.0/24

Tenant Bvm 1

10.0.2.3

Tenant Bvm 2

10.0.0.4

Tenant Cvm 1

10.0.2.5

Tenant Avm 1

10.0.0.2

Physical Router

gw: 10.0.0.1

Multiple Flat Network

Tenant Avm 2

10.0.2.6


gw: 10.0.2.1

http://docs.openstack.org/network-admin/admin/content/use_cases.html


8

OpenStackのシステム構成; OpenStackを選択する理由

overlay tunnel


Tenant Bvm 1

10.0.2.3172.21.0.3

Tenant Bvm 2

10.0.0.4172.21.0.4

Tenant Cvm 1

10.0.2.5

Tenant Avm 1

10.0.0.2172.21.0.2

Physical Router

gw: 10.0.0.1

Multiple Flat and Multiple Private Network in Overlay

Tenant A Private Network172.21.0.0/24

Tenant Avm 2

10.0.2.6172.21.0.6

Tenant B Private Network172.21.0.0/24


gw: 10.0.2.1


9


・ObjectストレージとBlockストレージのサポート https://wiki.openstack.org/wiki/CinderSupportMatrix http://docs.openstack.org/developer/swift/ !・「自分たちが実現したいこと」に合わせて、使いたいモジュールを利用できる

=>> モジュール間疎結合な構成 =>> お名前.com VPS KVM, ConoHa VPS KVMの例>>

!=>「OpenStackが様々なサービスを動かす共通インフラ」にできるのでは !

https://wiki.openstack.org/wiki/CinderSupportMatrix

http://docs.openstack.org/developer/swift/


10

GMOインターネットの仮想化サービス(2013/12版)(1) お名前.com VPS VZ

(2) GMOアプリクラウド

GMOクラウド Public (Xen, KVM)

GMOインターネットグループの仮想化サービス(独立性)

GMOクラウド VPS

(3) お名前.com Desktopクラウド

従量制、API開発機能あり

ソーシャルアプリ・webの運用、専用サーバのハイブリッド運用、Fusion-IO専用サーバ、その他カスタマイズ構成可

KVM、月額課金、Plesk

Hyper-V3, Thin ClientサービスVirtuozzo(OpenVZベース)、 OS仮想化(コンテナ)

(4) お名前.com VPS KVM(OpenStack Diablo環境) Linux KVM自由度、リソースきっちり

EL6, KVM運用ノウハウ等

SQALE (payperboy&co)PaaS従量制、API開発機能あり

VDI, リモートDesktop環境として

VPSからクラウドへ移行できる機能

PaaS on IaaSで稼働

(5) ConoHa(OpenStack Grizzly環境) Linux KVM !IP追加、IPv6対応、複数VM構成のための機能など “使い方志向”

(6) お名前.com VPS Hyper-VHyper-V3のVPSサービスWindows VPS環境として

新規のサービスブランドとして「インフラ・バックボーン」としての考えみる

MakeShop (SaaS) Shopping cart


Nova (compute service)

OpenStack DiabloOpenStack Diablo : お名前.com VPS KVM サービス

・OpenStack Diabloを使ったパブリックサービス(日本で最初) ・Flatなネットワーク構成にGlobal IP x1をvmに払い出す、Local disk使用

Swift (object storage)

Glance (Image service)

nova-network

Quantum (networking service)

Keystone (Identity service)

nova-volumeHorizon

(Dashboard)nova-scheduler

⇧token処理, ssh key

⇧OS(CentOS 6)img

⇧未使用(cinder相当)

⇧未使用

⇧未使用

⇧未使用

⇧Flat VLAN

利用モジュール

⇧利用

nova-compute⇧利用

nova-api⇧利用

gmo-api

nova-console

snapshot

serial console

virtio on/off

iso mount

ldap dhcp

ldap sftp

nova-vncproxy⇧利用

<=修正利用

l3-agent⇧未使用

未使用モジュール


12

OpenStack Diablo: お名前.com VPS KVM ネットワーク

Manage HostsManage Hosts

管理系

L3 SWL3 SW

consoleconsole

consoledhcp

Internet

consolevnc

サービス系

API/nova ManageKeystoneGlance

mqmqAPI / Manage

mysqldb

nova DBkeystone DB

sftpsftp

API / Managemysql

db会員/課金 DB

StorageStorage

ISO storage(NFS)

mqldap

API / Manageコンパネweb (.Net)

API

nova Computenova Compute


nova Compute



nova Compute

コンパネ系

glanceimage

RAID 10 local disk RAID 10 local disk

顧客global IPネットワーク

API系global IPネットワーク

Manageネットワーク (API, DB, mq, Storage)

vm

vm

vm vm vm

vmvm

vmvmvmvm

l3-agent は使わずHWまたはアプライアンスのL3を使用


13

OpenStack Diablo: お名前.com VPS KVM 顧客側ネットワーク


Tenant Bvm 1

10.0.2.3

Tenant Bvm 2

10.0.0.4

Tenant Cvm 1

10.0.2.5

Tenant Avm 1

10.0.0.2

Physical Router

gw: 10.0.0.1

Multiple Flat Network

Tenant Avm 2

10.0.2.6


gw: 10.0.2.1

OpenStack Diablo : お名前.com VPS KVM サービス側のネットワーク・Global IPのセグメントは/24単位で物理ルーター(L3)に設定・Global IPのセグメントは、VLANで管理されている・OpenStackのnova-networkにネットワークの設定追加・vmに1 IPごと払いだされる !

Diabloの当時、Quantumは開発が始まったばかりで、複雑な構成はできなかった


!!!!!Quantum (networking service)

Nova (compute service)

OpenStack GrizzlyOpenStack Grizzly : ConoHa VPS KVM サービス

・OpenStack Grizzlyを使ったパブリックサービス(日本で最初) ・Flatなネットワーク + Open vSwitch Edge Overlay(gre tunnel)によるvm間ローカルネットワーク接続の提供、IPv6-IPv4 Dual Stack、追加IP、Local disk使用

Swift (object storage)

Glance (Image service)

nova-network

Keystone (Identity service)

nova-scheduler

⇧token処理, ssh key

⇧OS(CentOS 6)img

⇧未使用⇧Quantumに移行

利用モジュール

⇧利用

nova-compute⇧利用

nova-api⇧利用

gmo-api

nova-console

snapshot

serial console

virtio on/off

iso mount

ldap dhcp4/6

ldap sftp

nova-vncproxy⇧利用

<=修正利用

GlusterFS

Horizon (Dashboard)⇧未使用

⇧ovs Overlay network

Cinder (Block service)⇧未使用

l3-agent⇧未使用

lbaas-agent⇧未使用

dhcp-agent⇧未使用

未使用モジュール


OpenStack Grizzly: ConoHa VPS KVM ネットワークl3-agent は使わずHWまたはアプライア

ンスのL3を使用

Manage Hosts Manage Hosts

管理系

L3 SWL3 SW

consolesftp

consoleconsole

Internet

consolevnc

サービス系

API/nova ManageKeystoneGlance

mqmqAPI / Manage

MariaDBdbnova DB

keystone DBglance DB

API / Managemysql

db会員/課金 DB

ISO storage(GlusterFS x4 Node)

mqldap

API / Manageコンパネweb (.Net)

API



nova Compute



nova Compute

コンパネ系

glanceimage

RAID 10 local disk RAID 10 local disk

顧客global IPネットワーク

API系global IPネットワーク

Manageネットワーク (API, DB, mq)

sftpdhcp

vm

vm

vm vm vm

vmvm

vmvmvmvm

sftpquantum

dbquantum DB

vm

Storageネットワーク (Glance API, Storage)

StorageStorage

gre tunnel


OpenStack Grizzly: ConoHa VPS KVM 顧客側ネットワーク

overlay tunnel


Tenant Bvm 1

10.0.2.3172.21.0.3

Tenant Bvm 2

10.0.0.4172.21.0.4

Tenant Cvm 1

10.0.2.5

Tenant Avm 1

10.0.0.2172.21.0.2

Physical Router

gw: 10.0.0.1

Multiple Flat and Multiple Private Network in Overlay

Tenant A Private Network172.21.0.0/24

Tenant Avm 2

10.0.2.6172.21.0.6

Tenant B Private Network172.21.0.0/24


gw: 10.0.2.1

OpenStack Grizzly : ConoHa VPS KVM サービス側のネットワーク・Global IPのセグメントは/23(IPv4), /64(IPv6)単位で物理ルーター(L3)に設定・Global IPのセグメントは、VLANで管理、ovsで動的設定・OpenStackのQuantumにネットワークの設定追加・vmに初期は1 IPごと払いだされる。別VLANからオプションとしてIPv4 x16まで追加払い出し、ovsによるOverlayネットワークにより、L2のPrivateネットワークを顧客のテナントに作成可能(無料) !

=>自由な顧客ネットワークの設置が可能になった (階層型ネットワーク) !顧客のサービスのスケールアウトに対応


17

ConoHa実装 : LibvirtHybridOVSBridgeDriverOpenStack Grizzly Docmentより


18

ConoHa実装 : VIF Driver : LibvirtHybridOVSBridgeDriver•Libvirt nwfilterの適用出来るovs + Linux Bridge兼用モード •構成的にはちょっと気持ち悪い気がする

•ovsだけでできないのか最初は試した>> libvirtのnwfilterがLinux Bridge用 (iptables, ebtables)

•Diablo Portingよりnwfilterが使いたかったので、選択 •virshコマンドとの併用

•tapがつなぐLinux Bridgeはnovaが叩く、作る (brctl addbr) •ovs-compat driverは不可 (今後なくなるので、まぁよし) •なので、ovs疎通できない状態でのvirsh startが可能

!•将来的にはどうなるのか、このモードは •ovs, OpenFlowでのfirewall driverが進化が進むと... •firewall driverもnovaからneutronに移行期 •Neutron: Firewall as a service


19

◎OpenStackの独自カスタマイズの概要•Shutoff (ACPI shutdown)機能の追加 (Diablo ~) •libvirt driverへの追加 !•IPv4/IPv6 DualStack DHCP agent構成 (Grizzly) •ISC dhcpd(ldap backend)を使用する(Diablo ~) !•vm VIFの修正 (Diablo) •わかりやすい仮想Network Interface命名 !•GMO API (VirtIO on/off, ISO boot, snapshot) !•Quantum periodic_interval, MariaDB

!!!

!!


libvirt driverの改修例として・vmのACPIを使った正常shutdownを試みるcallの実装(shutoff) !・vmの停止はlibvirtのドライバーでは強制停止しか無い

=> 調べたらXenAPI(XenServer用)ではドライバーに機能がある !・何故無いのか

・一般的な従量時間課金クラウドでは、即座に停止しないと課金が進んでしまう => でもやっぱりほしい => OpenStack summit 2013, Nov., HKでもHitachi Data Systemsの製品では、OpenStack driverに同じように追加したと言ってました

!・従量時間課金ではないモデルで使用する(われわれ)とお客さんには需要

20

ConoHa実装 : shutoff (ACPI shutdown) (1)


21

ConoHa実装 : shutoff (ACPI shutdown) (2)--- nova-stable-grizzly/nova/virt/libvirt/driver.py 2013-11-19 17:59:31.000000000 +0900 +++ usr/share/pyshared/nova/virt/libvirt/driver.py 2013-11-15 01:13:34.000000000 +0900 !>> snip(抜粋) << def patch_tpool_proxy(): """eventlet.tpool.Proxy doesn't work with old-style class in __str__() @@ -690,6 +701,76 @@ for (network, mapping) in network_info: self.vif_driver.unplug(instance, (network, mapping)) !+ def _shutoff(self, instance): + try: + virt_dom = self._lookup_by_name(instance['name']) + except exception.NotFound: + virt_dom = None + + # If the instance is already terminated, we're still happy + # Otherwise, destroy it + old_domid = -1


22

ConoHa実装 : shutoff (ACPI shutdown) (3)+ if virt_dom is not None: + try: + old_domid = virt_dom.ID() + #virt_dom.destroy() + virt_dom.shutdown() + except libvirt.libvirtError as e: + is_okay = False + errcode = e.get_error_code() + if errcode == libvirt.VIR_ERR_OPERATION_INVALID: + # If the instance is already shut off, we get this: + # Code=55 Error=Requested operation is not valid: + # domain is not running + (state, _max_mem, _mem, _cpus, _t) = virt_dom.info() + state = LIBVIRT_POWER_STATE[state] + if state == power_state.SHUTDOWN: + is_okay = True + + if not is_okay: + with excutils.save_and_reraise_exception(): + LOG.error(_("Error from libvirt during shutoff. " + "Code=%(errcode)s Error=%(e)s") % + locals(), instance=instance) + + + def _wait_for_shutoff(expected_domid): + """Called at an interval until the VM is gone.""" + # NOTE(vish): If the instance disappears during the destroy + # we ignore it so the cleanup can still be + # attempted because we would prefer destroy to + # never fail.


23

ConoHa実装 : shutoff (ACPI shutdown) (4)+ def _wait_for_shutoff(expected_domid): + """Called at an interval until the VM is gone.""" + # NOTE(vish): If the instance disappears during the destroy + # we ignore it so the cleanup can still be + # attempted because we would prefer destroy to + # never fail. + try: + dom_info = self.get_info(instance) + state = dom_info['state'] + new_domid = dom_info['id'] + except exception.NotFound: + LOG.error(_("During wait shutoff, instance disappeared."), + instance=instance) + raise utils.LoopingCallDone() + + if state == power_state.SHUTDOWN: + LOG.info(_("Instance shutoff successfully."), + instance=instance) + raise utils.LoopingCallDone() + + # NOTE(wangpan): If the instance was booted again after destroy, + # this may be a endless loop, so check the id of + # domain here, if it changed and the instance is + # still running, we should destroy it again. + # see https://bugs.launchpad.net/nova/+bug/1111213 for more details + if new_domid != expected_domid: + LOG.info(_("Instance may be started again."), + instance=instance) + kwargs['is_running'] = True + raise utils.LoopingCallDone() +


24

ConoHa実装 : shutoff (ACPI shutdown) (5)+ kwargs = {'is_running': False} + timer = utils.FixedIntervalLoopingCall(_wait_for_shutoff, old_domid) + timer.start(interval=0.5).wait() + if kwargs['is_running']: + LOG.info(_("Going to shutoff instance again."), instance=instance) + self._shutoff(instance) + def _destroy(self, instance): try: virt_dom = self._lookup_by_name(instance['name']) @@ -714,11 +795,6 @@ state = LIBVIRT_POWER_STATE[state] if state == power_state.SHUTDOWN: is_okay = True


--- nova-stable-grizzly/nova/compute/manager.py 2013-11-19 17:59:31.000000000 +0900 +++ ./usr/share/pyshared/nova/compute/manager.py 2013-07-10 12:02:46.000000000 +0900 >>> snip(抜粋) <<< !@@ -1422,6 +1400,23 @@ @reverts_task_state @wrap_instance_event @wrap_instance_fault + def shutoff_instance(self, context, instance): #P.Hide + """Stopping an instance on this host.""" + self._notify_about_instance_usage(context, instance, "shut_off.start") + #self.driver.power_off(instance) + self.driver.shut_off(instance) + current_power_state = self._get_power_state(context, instance) + instance = self._instance_update(context, instance['uuid'], + power_state=current_power_state, + vm_state=vm_states.STOPPED) + #expected_task_state=None, #P.Hide + #task_state=None) + self._notify_about_instance_usage(context, instance, "shut_off.end") + + @exception.wrap_exception(notifier=notifier, publisher_id=publisher_id()) + @reverts_task_state + @wrap_instance_event + @wrap_instance_fault def stop_instance(self, context, instance): """Stopping an instance on this host.""" self._notify_about_instance_usage(context, instance, "power_off.start")

25



--- nova-stable-grizzly/nova/compute/api.py 2013-11-19 17:59:31.000000000 +0900 +++ ./usr/share/pyshared/nova/compute/api.py 2013-07-03 23:13:11.000000000 +0900 >>> snip(抜粋) <<< ! def stop(self, context, instance, do_cast=True): """Stop an instance.""" @@ -1298,6 +1295,25 @@ @wrap_check_policy @check_instance_lock @check_instance_host + @check_instance_state(vm_state=[vm_states.ACTIVE, vm_states.RESCUED, + vm_states.ERROR, vm_states.STOPPED], + task_state=[None]) + def shutoff(self, context, instance, do_cast=True): #P.Hide + """Shutoff an instance.""" + LOG.debug(_("Going to try to shutoff instance"), instance=instance) + + instance = self.update(context, instance, + task_state=None, + expected_task_state=None, + progress=0) + + self._record_action_start(context, instance, instance_actions.STOP) + + self.compute_rpcapi.shutoff_instance(context, instance, cast=do_cast) + + @wrap_check_policy + @check_instance_lock + @check_instance_host @check_instance_state(vm_state=[vm_states.STOPPED]) def start(self, context, instance):

26



--- nova-stable-grizzly/nova/compute/rpcapi.py 2013-11-19 17:59:31.000000000 +0900 +++ ./usr/share/pyshared/nova/compute/rpcapi.py 2013-07-03 23:13:11.000000000 +0900 !>>> snip(抜粋) <<< @@ -260,7 +261,7 @@ ! def detach_interface(self, ctxt, instance, port_id): instance_p = jsonutils.to_primitive(instance) - self.cast(ctxt, self.make_msg('detach_interface', + return self.call(ctxt, self.make_msg('detach_interface', # Y.Kawada instance=instance_p, port_id=port_id), topic=_compute_topic(self.topic, ctxt, None, instance), version='2.25') @@ -583,6 +584,13 @@ instance=instance_p), topic=_compute_topic(self.topic, ctxt, None, instance)) !+ def shutoff_instance(self, ctxt, instance, cast=True): #P.Hide + rpc_method = self.cast if cast else self.call + def shutoff_instance(self, ctxt, instance, cast=True): #P.Hide + rpc_method = self.cast if cast else self.call + instance_p = jsonutils.to_primitive(instance) + return rpc_method(ctxt, self.make_msg('shutoff_instance', + instance=instance_p), + topic=_compute_topic(self.topic, ctxt, None, instance)) + def suspend_instance(self, ctxt, instance): instance_p = jsonutils.to_primitive(instance) self.cast(ctxt, self.make_msg('suspend_instance',

27



--- ./nova-stable-grizzly/nova/api/openstack/compute/contrib/server_start_stop.py 2013-11-19 17:59:31.000000000 +0900 +++ ./usr/share/pyshared/nova/api/openstack/compute/contrib/server_start_stop.py 2013-07-03 23:13:11.000000000 +0900 @@ -62,6 +62,18 @@ raise webob.exc.HTTPConflict(explanation=e.format_message()) return webob.Response(status_int=202) !+ @wsgi.action('os-shutoff') + def _shutoff_server(self, req, id, body): #P.Hide + """Shutoff an instance.""" + context = req.environ['nova.context'] + instance = self._get_instance(context, id) + LOG.debug(_('shutoff instance'), instance=instance) + try: + self.compute_api.shutoff(context, instance) + except exception.InstanceNotReady as e: + raise webob.exc.HTTPConflict(explanation=e.format_message()) + return webob.Response(status_int=202) + ! class Server_start_stop(extensions.ExtensionDescriptor): """Start/Stop instance compute API support."""

28



同様の改修として、次の機能を実装してい・vmのserial consoleを接続(nova-consoleのシリアルコンソール化) !・noVNC拡張

・keymap変更機能(ja or us) ・vnc video driver変更機能(cirrus or vmvga)

!・snapshot機能拡張、disk拡張、zero領域の圧縮(convert)

・顧客のqcow2 disk imageの操作について !・virtIOの on/off 切り替え機能

・virtIOドライバーが無いOSでも、完全仮想化に切り替えて起動できるように、切替機能

!・ISO boot機能

・本来glance imageにISOを登録して使用する機能だが、独自実装

29

ConoHa実装 : GMO API


30

ConoHa実装 : IPv4/IPv6 DualStack DHCP agent構成dnsmasqを起動するdhcp agent •ipv6 ipv4 Dualstack稼働がうまく稼働しなかった => 一つのVLANにDualstack(IPv4/IPv6)のdhcp(dnsmasqd)起動がエラーになった !•設計上 dnsmasq を自動で起動する必要はない (Network追加 << IP追加時のみ) !ISC dhcpd driver(未使用) https://blueprints.launchpad.net/neutron/+spec/quantum-dhcp !ISC dhcpdをIPv4, IPv6べつに起動 ldapにより稼働させる(冗長性も向上)


・OpenStack Grizzly Quantum にて・ovs agentへの定期的状態確認の間隔

=> QuantumのDBの負荷が高くなってしまう =>> /etc/quantum/quantum.conf

periodic_interval = 40 =>> periodic_interval = 1200 に変更 report_interval = 4 =>> report_interval = 120 に変更

=>> /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini にも同様に入れる

!・本来、このようなことはSQLで実装すべきではない、のではないか

=> KVSなどでやるべき !・MariaDB: Active - Activeで稼働, QuantumのLocalにDB配置、socket接続に変更してチューニング

31

ConoHa実装 : Quantum periodic_interval, MariaDB


32

◎OpenStack以外に利用しているOSS•noVNC (html5 vnc): http://kanaka.github.io/noVNC/ •ブラウザのversion upに追随して幾つか最新からのback port

•anyterm: http://anyterm.org/ •webでのserial console用のTerminalとして利用

•conserver: http://www.conserver.com/ •anyterm > nova-console > conserver > virsh consoleと接続連携するための virsh consoleの接続情報を管理、コンソール機能

•collectd: http://collectd.org/ •コンパネに表示するCPU, disk io, network trafficなどの情報をそのホスト上でRRDファイルでとり続けるツール

•Nagios Core: http://www.nagios.org/projects/nagioscore •監視ツール、サービスが落ちた場合の通知、障害検知、なにか不明なバグが発生した場合に、ワークアラウンド・アクションを自動で実行するツール

http://kanaka.github.io/noVNC/

http://anyterm.org/

http://www.conserver.com/

http://collectd.org/

http://www.nagios.org/projects/nagioscore


33

コントロールパネル(cp)

nova-novncproxy(noVNC) + nginx : html5 VNC nova-console + anyterm(旧Diabloより) : serial console

iPad対応(noVNC)とかも


34


35


36

◎コンパネデモ(拡張部分について)


未解決事項 •ローカルネットワークの細かい見直し •要因: 一部libvirt nwfilter機能に手を入れたことによる弊害 !現在割り当て可能・10.0.0.0/24 ・172.16.0.0/24 ・192.168.0.0/24 これしかない !=> VPNなどを構成すると、既存ネットワークとのアドレスの重複などの可能性大、問題有り !もう少し、自由に割り当てできるようにする

37

◎今後のConoHaの課題 (1)


38

今後のConoHaの課題 (2)未解決事項 •未解決のquamtum metadata agent構成 •要因: dhcpを独自実装した弊害(IPv4/IPv6 DualStack ldap dhcpd) !いわゆる、”cloud-init” の動作現在、対応中 >> config driveなどで解決できるか !・injection script機能と共に、起動時設定を流し込みできるようにする >> VM TemplateとしてのGlance保存機能に使えるように


未解決事項・API公開実装

・L7 LB(reverse proxy)配下でURIベースの公開設定・開けたくないAPIなどにURIマスク(ACL)でセキュリティ実装する・入力値チェックはまだ実装されてないので独自拡張が必要 =>> v3 API(Icehouseから)入りそう

!・要因: 独自機能拡張

=>> extenstion APIとしてユーザーから見れるようにするのが良いのか !・OpenStack client APIとしての互換性が出るようにする・3rd partyツールが使える

・Vagrant OpenStack provider pluginを使えるようにしたい(第一目標) ・その他、Fog, boto など対応ツールとの互換性(Interoperability)

!

39

今後のConoHaの課題 (3)


40

今後のConoHaの課題 (4)未解決事項・Block storage(Cinder)

ConoHaにBlock storageをリリースしたいコスト感ある構成 !

•要因: 価格感 (市販のストレージはやっぱり高い) !•検討

・zfs cinder storage (low performance, replication image) ・LVM thin provisioning on cinder driver (Havana以降) ・GlusterFS BD volume (GlusterFS 3.5 or lator)

　・直接LVM thinでアクセスするGlusterFSの新機能


41

◎まとめ・OpenStack Diablo、OpenStack Grizzlyとパブリックな仮想化サービスをエンドユーザーに提供しています。

・Diabloではほとんど動かない基本機能が有り、大変でした・一方、Grizzlyでは基本機能は動くようになっているので、製品としてのDiablo(お名前.com VPS KVM)からの機能引き継ぎなどの拡張機能や、やりたかったネットワークの機能をエンドユーザーに簡単に使ってもらえる機能に注力できました。

!・問題点としては、独自に手を入れたことによるOpenStackそのものとの機能の整合性の問題があります。

・そのまま使い続ける、運用し続けるには問題ないです。・OpenStackのエコシステム(豊富なクライアントツール)を互換性を持ったまま使えるようにすることが課題(openstackclient, Vagrant, Fog, boto, etc.)になります。・独自に手を入れ続けるのか、コミットして修正されることを望むのか

=>> なるべく、コミットすることを選択しましょう


42

OpenStackを使ったパブリッククラウドサービスのご紹介 !ご清聴ありがとうございました

Technology

OpenStack base public cloud service by GMO Internet Inc., at 2013/12/12 Okinawa Open Days 2013