OpenStack base public cloud service by GMO Internet; 2013/12/12; Okinawa Open Days 2013

1. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStackを採用したパブリッククラウド
サービスのご紹介
Engineering SIDE
GMOインターネット株式会社
システム本部 サービス開発部
システムインテグレーションチーム
郷古 直仁
Okinawa Open Days 2013 ; 2013/12/12
1

2. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
まずは自己紹介
•
郷古 直仁 (ゴウコ ナオト, 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環境) ; インフラとか
2

3. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
アジェンダ
•
◎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)
•
◎今後の課題
•
◎まとめ
3

4. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
◎OpenStackのシステム構成; OpenStackを選択する理由
OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?
・OpenStackはオープンソースであり、だれでも利用したり開発に参加したりで
きる =>> http://www.openstack.org/
4

5. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStackのシステム構成; OpenStackを選択する理由
OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?
・Pythonで書いてあるので、実働するソースが可読しやすい
5

6. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStackのシステム構成; OpenStackを選択する理由
OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?
・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
6

7. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStackのシステム構成; OpenStackを選択する理由
OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?
・Neutronによりネットワーク構成モデルの自由度が高い(Flat, VLAN, SDN)
例) http://docs.openstack.org/network-admin/admin/content/use_cases.html
Multiple Flat Network
Physical Router
gw: 10.0.0.1
Shared Network
10.0.0.0/24
Tenant A
vm 1
10.0.0.2
gw: 10.0.2.1
Shared Network
10.0.2.0/24
Tenant B
vm 2
10.0.0.4
Tenant C
vm 1
10.0.2.5
Tenant B
vm 1
10.0.2.3
Tenant A
vm 2
10.0.2.6
7

8. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStackのシステム構成; OpenStackを選択する理由
Multiple Flat and Multiple Private Network in Overlay
Physical Router
gw: 10.0.0.1
Shared Network
10.0.0.0/24
Tenant A
vm 1
10.0.0.2
172.21.0.2
gw: 10.0.2.1
Shared Network
10.0.2.0/24
Tenant B
vm 2
10.0.0.4
172.21.0.4
Tenant C
vm 1
10.0.2.5
Tenant B
vm 1
10.0.2.3
172.21.0.3
Tenant A
vm 2
10.0.2.6
172.21.0.6
Tenant B Private Network
172.21.0.0/24
Tenant A Private Network
172.21.0.0/24
overlay tunnel
8

9. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStackのシステム構成; OpenStackを選択する理由
OpenStackを使ってシステムを作り、サービスシステムを作ることを選択するとは?
・ObjectストレージとBlockストレージのサポート
https://wiki.openstack.org/wiki/CinderSupportMatrix
http://docs.openstack.org/developer/swift/
!
・「自分たちが実現したいこと」に合わせて、使いたいモジュールを利用できる
=>> モジュール間疎結合な構成
=>> お名前.com VPS KVM, ConoHa VPS KVMの例>>
!
=>「OpenStackが様々なサービスを動かす共通インフラ」に
できるのでは
!
9

10. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
GMOインターネットの仮想化サービス(2013/12版)
(1) お名前.com VPS VZ
(3) お名前.com Desktopクラウド
Virtuozzo(OpenVZベース)、
OS仮想化(コンテナ)
Hyper-V3, Thin Clientサービス
(5) ConoHa
VDI, リモートDesktop環境として
(OpenStack Grizzly環境)
Linux KVM
(6) お名前.com VPS Hyper-V
(2) GMOアプリクラウド
Hyper-V3のVPSサービス
Windows VPS環境として
(4) お名前.com VPS KVM
(OpenStack Diablo環境)
Linux KVM
自由度、リソースきっちり
ソーシャルアプリ・webの運用、
専用サーバのハイブリッド運用、
EL6, KVM
Fusion-IO専用サーバ、その他カス 運用ノウハ
タマイズ構成可
ウ等
!
IP追加、IPv6対応、複数VM構
成のための機能など
使い方志向
新規のサービスブランドとして
「インフラ・バックボーン」とし
ての考えみる
GMOインターネットグループの仮想化サービス(独立性)
GMOクラウド Public (Xen, KVM)
従量制、API開発機能あり
GMOクラウド VPS
KVM、月額課金、Plesk
MakeShop (SaaS)
Shopping cart
PaaS on IaaSで稼働
VPSからクラウドへ
移行できる機能
SQALE (payperboy&co)
PaaS従量制、API開発機能あり
10

11. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStack Diablo
OpenStack Diablo : お名前.com VPS KVM サービス
・OpenStack Diabloを使ったパブリックサービス(日本で最初)
・Flatなネットワーク構成にGlobal IP x1をvmに払い出す、Local disk使用
利用モジュール
未使用モジュール
Nova
nova-compute
(compute service) ⇧利用
nova-network
⇧Flat VLAN
nova-scheduler
⇧利用
Glance
(Image service)
⇧OS(CentOS 6)img
Keystone
(Identity service)
⇧token処理, ssh key
nova-api
⇧利用
nova-vncproxy
⇧利用
Swift
(object storage)
⇧未使用
Horizon
(Dashboard)
nova-volume
⇧未使用(cinder相当) ⇧未使用
gmo-api
snapshot
ldap dhcp
virtio on/off
ldap sftp
iso mount
serial console
nova-console <=修正利用
Quantum
(networking service)
⇧未使用
l3-agent
⇧未使用

12. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStack Diablo: お名前.com VPS KVM ネットワーク
l3-agent
Internet
は使わずHWまたはアプライア
ンスのL3を使用
コンパネ系
L3 SW
L3 SW
サービス系
顧客global IPネットワーク
db
会員/課金 DB
API系global IPネットワーク
nova Compute
nova Compute
nova Compute
nova Compute
nova Compute
vm
nova Compute
nova Compute
nova Compute
nova Compute
nova Compute
RAID 10 local disk
API / Manage
コンパネweb (.Net)
API / Manage
mysql
API
管理系
Manage Hosts
Manage Hosts
vm
vm vm
vm
sftp
sftp
RAID 10 local disk
vm
console
console
vm
mq
ldap
vm
console
dhcp
vm
console
vnc
vm
API / Manage
mysql
nova DB
keystone DB
API/nova Manage
Keystone
Glance
glance
image
vm
mq
mq
db
Manageネットワーク (API, DB, mq, Storage)
Storage
Storage
ISO storage
(NFS)
12

13. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStack Diablo: お名前.com VPS KVM 顧客側ネットワーク
OpenStack Diablo : お名前.com VPS KVM サービス側のネットワーク
・Global IPのセグメントは/24単位で物理ルーター(L3)に設定
・Global IPのセグメントは、VLANで管理されている
・OpenStackのnova-networkにネットワークの設定追加
・vmに1 IPごと払いだされる
!
Diabloの当時、Quantumは開発が始まったばかりで、複雑な構成はできなかった
Multiple Flat Network
Physical Router
gw: 10.0.0.1
Shared Network
10.0.0.0/24
Tenant A
vm 1
10.0.0.2
gw: 10.0.2.1
Shared Network
10.0.2.0/24
Tenant B
vm 2
10.0.0.4
Tenant C
vm 1
10.0.2.5
Tenant B
vm 1
10.0.2.3
Tenant A
vm 2
10.0.2.6
13

14. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStack Grizzly
OpenStack Grizzly : ConoHa VPS KVM サービス
・OpenStack Grizzlyを使ったパブリックサービス(日本で最初)
・Flatなネットワーク + Open vSwitch Edge Overlay(gre tunnel)によるvm間ローカ
ルネットワーク接続の提供、IPv6-IPv4 Dual Stack、追加IP、Local disk使用
利用モジュール
未使用モジュール
Nova
nova-compute
(compute service) ⇧利用
nova-api
⇧利用
nova-scheduler
⇧利用
Glance
(Image service)
⇧OS(CentOS 6)img
Keystone
(Identity service)
⇧token処理, ssh key
nova-vncproxy
⇧利用
nova-network
Swift
⇧Quantumに移行 (object storage)
⇧未使用
Cinder
Horizon
(Block service)
(Dashboard)
⇧未使用
⇧未使用
gmo-api
snapshot
ldap dhcp4/6
virtio on/off
ldap sftp
iso mount
GlusterFS
serial console
nova-console <=修正利用
!
!
!
!
!l3-agent
lbaas-agent
⇧未使用
⇧未使用
dhcp-agent
⇧未使用
Quantum
(networking service)
⇧ovs Overlay network

15. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStack Grizzly: ConoHa VPS KVM ネットワーク
l3-agent
Internet
は使わずHWまたはアプライア
ンスのL3を使用
コンパネ系
L3 SW
L3 SW
サービス系
顧客global IPネットワーク
会員/課金 DB
API系global IPネットワーク
nova Compute
nova Compute
nova Compute
nova Compute
nova Compute
vm
nova Compute
nova Compute
nova Compute
nova Compute
nova Compute
vm vm
Manage Hosts
vm
sftp
dhcp
vm
sftp
quantum
RAID 10 local disk
API / Manage
コンパネweb (.Net)
API / Manage
mysql
RAID 10 local disk
db
API
管理系
Manage Hosts
vm
vm
console
sftp
db
quantum DB
gre tunnel
vm
console
console
vm
console
vnc
vm
API / Manage
MariaDB
db
nova DB
keystone DB
glance DB
API/nova Manage
Keystone
Glance
glance
image
vm
mq
mq
vm
mq
ldap
Manageネットワーク (API, DB, mq)
Storage
ISO storage
(GlusterFS x4 Node)
Storageネットワーク (Glance API, Storage)
Storage

16. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
OpenStack Grizzly: ConoHa VPS KVM 顧客側ネットワーク
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ネットワークを顧客のテ
ナントに作成可能(無料)
Multiple Flat and Multiple Private Network in Overlay
!
=>自由な顧客ネットワーク
の設置が可能になった
(階層型ネットワーク)
!
顧客のサービスの
スケールアウトに対応
Physical Router
gw: 10.0.0.1
Shared Network
10.0.0.0/24
Tenant A
vm 1
10.0.0.2
172.21.0.2
gw: 10.0.2.1
Shared Network
10.0.2.0/24
Tenant B
vm 2
10.0.0.4
172.21.0.4
Tenant C
vm 1
10.0.2.5
Tenant B Private Network
172.21.0.0/24
Tenant A Private Network
172.21.0.0/24
overlay tunnel
Tenant B
vm 1
10.0.2.3
172.21.0.3
Tenant A
vm 2
10.0.2.6
172.21.0.6

17. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : LibvirtHybridOVSBridgeDriver
OpenStack Grizzly Docmentより
17

18. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
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
18

19. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
◎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
!
!
!
!
19

20. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : shutoff (ACPI shutdown) (1)
libvirt driverの改修例として
・vmのACPIを使った正常shutdownを試みるcallの実装(shutoff)
!
・vmの停止はlibvirtのドライバーでは強制停止しか無い
=> 調べたらXenAPI(XenServer用)ではドライバーに機能がある
!
・何故無いのか
・一般的な従量時間課金クラウドでは、即座に停止しないと課金が進んでしま
う
=> でもやっぱりほしい
=> OpenStack summit 2013, Nov., HKでもHitachi Data Systemsの
製品では、OpenStack driverに同じように追加したと言ってました
!
・従量時間課金ではないモデルで使用する(われわれ)とお客さんには需要
20

21. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
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
21

22. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
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.
22

23. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
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()
23

24. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
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
24

25. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : shutoff (ACPI shutdown) (6)
--- 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

26. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : shutoff (ACPI shutdown) (7)
--- 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

27. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : shutoff (ACPI shutdown) (8)
--- 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

28. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : shutoff (ACPI shutdown) (9)
--- ./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

29. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : GMO API
同様の改修として、次の機能を実装してい
・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

30. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
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により稼働させる
(冗長性も向上)
30

31. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
ConoHa実装 : Quantum periodic_interval, MariaDB
・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

32. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
◎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
•監視ツール、サービスが落ちた場合の通知、障害検知、なにか不明な
バグが発生した場合に、ワークアラウンド・アクションを自動で実行
するツール
32

33. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
コントロールパネル(cp)
iPad対応(noVNC)とかも
nova-novncproxy(noVNC) + nginx : html5 VNC
nova-console + anyterm(旧Diabloより) : serial console
33

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

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

36. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
◎コンパネ デモ(拡張部分について)
36

37. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
◎今後のConoHaの課題 (1)
未解決事項
•ローカルネットワークの細かい見直し
•要因: 一部libvirt nwfilter機能に手を入れたことによる弊害
!
現在 割り当て可能
・10.0.0.0/24
・172.16.0.0/24
・192.168.0.0/24
これしかない
!
=> VPNなどを構成すると、
既存ネットワークとのアドレスの
重複などの可能性大、問題有り
!
もう少し、自由に割り当てできるようにする
37

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

39. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
今後のConoHaの課題 (3)
未解決事項
・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

40. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
今後の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の新機能
40

41. OpenSackを採用したパブリッククラウドサービスのご紹介
Engineering SIDE
◎まとめ
・OpenStack Diablo、OpenStack Grizzlyとパブリックな仮想化サービス
をエンドユーザーに提供しています。
・Diabloではほとんど動かない基本機能が有り、大変でした
・一方、Grizzlyでは基本機能は動くようになっているので、製品としての
Diablo(お名前.com VPS KVM)からの機能引き継ぎなどの拡張機能や、や
りたかったネットワークの機能をエンドユーザーに簡単に使ってもらえる機能
に注力できました。
!
・問題点としては、独自に手を入れたことによるOpenStackそのものとの機能
の整合性の問題があります。
・そのまま使い続ける、運用し続けるには問題ないです。
・OpenStackのエコシステム(豊富なクライアントツール)を互換性を持った
まま使えるようにすることが課題(openstackclient, Vagrant, Fog, boto,
etc.)になります。
・独自に手を入れ続けるのか、コミットして修正されることを望むのか
=>> なるべく、コミットすることを選択しましょう
41

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