1st ocdet baremetal mtg openstack baremetal compute by gmo appscloud

GMOアプリクラウドでのOpenStack Baremetal

1

GMOアプリクラウドでの OpenStack Baremetal

2015/01/28

GMOインターネット株式会社システム本部郷古　直仁高田　真澄 (Ironic) 柳　匡哉 (Ironic)

第1回 OCDET ベアメタルWG 勉強会


・GMOアプリクラウドと Baremetal computing ・OpenStack Ironicから見たベアメタルに必要な要素・昔、今、現在進行形で使っているベアメタルツール・kickstart/preseed ・Relax-and-Recover ・cobbler + php + DB + Excel ・OpenStack Baremetal Compute(Ansible driver modified) + Ansible + cobbler + lldptool + Router.py ・[検証中]OpenStack Ironic Hyper-visor(IPA: Ironic Python Agent) + cloud-init + lldptool + Router.py (技術検証中)について [高田、柳]

2

アジェンダ


GMOアプリクラウドとは •  ソーシャルゲームをターゲット中心に、VLAN, LB, PKIなど必要な機能を搭載した、ゲーム専用クラウド

•  最新環境はOpenStack Havanaで提供(API) •  専用サーバはOpenStack Compute Baremetal (改造: 内容はのちほど) で提供


GMOアプリクラウド OpenStack標準構成 • テナントNetwork VLAN x2(external, internal)

•  neutron-LBaaS(Brocade ADX)にNAT outbound

•  cinder(3PAR, SSD)

>> BaremetalもVLAN x2が払い出される >> Baremetal serverらか見ると、bonding Interfaceの下に、tagged VLANが来ているのが、特徴


GMOアプリクラウド OpenStack Tenant NW


OpenStack Ironic <= OpenStack Compute Baremetal << kvm, xen, Hyper-Vと同様にBaremetalをコントロールするハイパーバイザとして抽象化するサービス開始点 >> SoftwareでなんとかHWをコントロールする

OpenStack を通して見たベアメタルに必要な要素


実際にOSが入ったBaremetalを使えるには、以下の要素が必要になる 1) Hardware Inventory Info. Discovery(MAC) 2) Server Hardware control/configuration(IPMI) 3) OS deployment and boot loader setup 4) Tenant-Isolation Network; HW-Switch setup 5) OS Network setup 6)  (Orchestration, Management)

7

OpenStack を通して見たベアメタルに必要な要素


a) 共有Networkがある場合、IP-MAC Addressのセキュリティ設定(IP/MAC/ARP/dhcp spoofing対策) (Exp] Cisco; port-security mac-address, etc.)

b) 課金量計処理とりあえず、OpenStackではFlavorがBaremetalを示したnova instance(server)として; =>> Ceilomenter (OpenStackの場合)

c) 入会課金情報管理 web GUIなど

8

さらに、XaaSとして提供するには


d) Hardware Monitoring/Management IBM: Director Server DELL: OpenManage Server Admin.(Dell-CIM) HP: Systems Insight Manager Supermicro: IPMI, SMCIPMITool IPMI(DCMI): Zabbix, etc.

OpenStack Baremetal Compute/IronicのInterfaceとしても利用するので必要 (Power on/off, state, serial console, virtual media) Ironic Hyper-visorの抽象化の恩恵(まだまだだが)

>> さて、Baremetalはこれまで、どうしてきた? 9

さらに、XaaSとして提供するには#2


1) kickstart/preseed install (without cobbler)

10

利用しているベアメタルツール: 昔、今、現在進行形

時期 2008年ぐらいまで、少数だと今でもたまにVirtual Mediaなどで利用

Boot Network(dhcp+tftp+pxe), Virtual Media, USB

OS Linux系(当初CentOS 5, Ubuntu 10.4) OS Network setup Human (Manual setting) or shell script NW Switch setup Human 設定台数 1, or 少数利用範囲非商用サービスのサーバ、開発サーバなど

大量生産には向かないネットワークインストールには、ローカルリポジトリがあったほうが良い


2) Relax-and-Recover(“rear”)

11


時期 2014 ‒ (実は最近) Boot boot(Virtual Media, USB, pxe) + ISO,NFS,

etc. OS Linux系 (SuSE ?) URL http://relax-and-recover.org/

https://github.com/rear OS Network setup Manual (cloned origin conf, shell script) NW Switch setup Human 設定台数 1, or 数十台利用範囲 OpenStack Computeのcloneに利用、本来

バックアップ用途、バックアップ元がliveで使える


3) Cobbler + php(expect) + DB + Excel

12


時期 2011/07 ‒ 現在まで(GMOアプリクラウド) Boot Pxeboot, ISO Virtual Media boot OS Linux, python 2.6 or lator URL http://www.cobblerd.org/ OS Network setup Manual (cloned origin conf, shell script) NW Switch setup Manual + php-expect script(Network

Team作成)(対象スイッチ: Cisco: Catalyst(IOS), Nexsus(NXOS), Brocade: VDX) LB: Brocade ADX

設定台数同時構築 1 or 数台利用範囲 GMOアプリクラウド非OpenStack環境で利用、

cobbler用のIP:MAC addressのInventory情報がExcelで管理されていて、phpのAPI経由で商材DBからvlanなど取得してデプロイする


Cobbler Kickstartなどをテンプレート化して、OSをネットワークインストール管理(pythonでできている) OSインストール後のPOSTネットワーク設定などを投入できる(bonding, vlan) 最近ver. 2.6になって、cobbler systemオブジェクトが増えると、pxe boot設定の生成が極端に遅くなった（泣）改造必要

Cobblerにhostname:IP:MAC Addressのインベントリ情報の投入時に利用

Python-openpyxl


GMOアプリクラウド(非OpenStack)専用サーバ 1) お客様、営業にMail申し込み、在庫調整確認

物理サーバの構成タイプ: ものすごく多数 2)  (manual)IDC構築依頼チケット(redmine) 3)  (manual)IDC構築スクリプト(cobbler)実行 4)  (manual)Network Switch allowed VLAN

(tenant: ext, int) 5)  (manual)Network Switch dis-allowed VLAN

dhcp 6)  (manual)検品、提供

>> OpenStack Baremetal Compute 化とこれらの自動処理対応を行った


4) OpenStack Baremetal Compute(Ansible driver modified) + Ansible + cobbler + lldptool + Router.py

15


時期 2014/04/22 ‒ 現在まで(GMOアプリクラウド) Boot Pxeboot (cobbler) OS Linux, python 2.6 or lator OS Network setup Ansible script NW Switch setup Ansible + lldpd + lldptool + Router.py

(NXOS patched by GMO) 設定台数同時構築 1 or 数台利用範囲 GMOアプリクラウド OpenStack Havana環境

で利用 (今現在は、お名前.comクラウドも同じ仕組で動作しています)


Router.py : Cisco IOS CLI automation https://code.google.com/p/cisco-ios-cli-automation/

Cisco純正のSDK”onePK”ではないのは ... Python Pyexpect が使われている、NXOS, IOSでだいたいOK


1)  コンパネで申し込み or APIとして、 Mailが流れてくる、在庫調整確認(ここだけ手動) 物理サーバタイプ(baremetal flavor) 　[a] HDD + disk SSD cached 　[b] HDD + ioDrive2 768GB

2)  IDC自動構築をスタッフツールで実行 nova boot ‒flavor=bare_flavor dummy-baremetal-img >ここをOpenStack Baremetal Computeで自動化 > Ansible + cobblerに処理が渡される

3)  検品(serverspec)、提供(nova status DB更新)

GMOアプリクラウド(OpenStack Berametal Compute)専用サーバ


OpenStack Baremetal Compute network(mod)


Baremetal seq: 0) 機材登録

baremetal-set-console(conserverの設定) nova baremetal-node-create : (IPMI IP addr, NIC1 MAC addr) nova baremetal-interface-add : (NIC2 MAC, NIC3 MAC, NIC4 MAC) MACなどは、cobbler上のExcel利用


nova boot seq: 1) call nova boot

nova boot [admin API only] (user apiとしてはbaremetalはまだflavorを選べない[public apiで表示されない]ようになっています)


nova boot seq: 2) generate data(host_vars) for Ansible on bare-comp node

Ansibleのdataで読み込まれるyaml data(host_vars)を生成 - root pw, ssh public key, VLAN(ext, int), IP address(ext, int), Flavor(host type), Image(OS type), target node(IPMI IP addr)


nova boot seq: 3) copy Ansible host_var.yaml to cobbler node

Ansibleのdataで読み込まれるyaml dataをcobbler nodeのansible playbook 領域にコピー ./baremetal/ansible/host_vars/<host_name>.yml


nova boot seq: 4) exec cobbler system add

cobblerにsystemオブジェクトの登録(OSの選定) cobbler system add -‒name=<host_name> --profile=<OS_type_kick_profile> --interface=eth0 -‒mac=<MAC> cobbler sync (pxe boot情報更新)


nova boot seq: 5) exec Ansible playbook on cobbler node

Ansibleが実行される実行時のinventoryは “cobbler dynamic inventory” を用いる ./baremetal/ansible/host_vars/<host_name>.yml


nova boot seq: 6) (in Ansible) lldptool network Switch discovery and SW setup

(Ansible) cobblerでOSインストール後、再起動 lldpadを起動、lldptool で SW の {SW hostname, sw IP, Port ID} 情報を取得、SW設定APIをcallして、SWのallowed VLANにVLAN(ext, int)の許可する設定をいれる


nova boot seq: 7) (in Ansible) setting up OS bonding network and VLAN(ext, int)

(Ansible) SWの設定が終わったら、OSのbonding設定、 VLAN(ext, int)の設定を投入、疎通を確認する >> ioDrive2などoptionがある場合には、ここでセットアップ、マウントする


nova boot seq: 8) (in Ansible) configuration test (serverspec)

(Ansible) VLAN dhcpをallowed VLANから外して、再起動。設定、ネットワークの疎通など確認をserverspecなどで実行、検品できたら、nova bootのstatusを “ACTIVE” にする


ここまで、summary •  OpenStack Havana の Baremetal Computeの処理を改修して、nova bootの過程でAnsibleを呼び出し、処理としてcobbler のインストール、Network SWの設定を行ってサービスを提供している。

>> cobblerの特性として、OSのインストールに時間がかかり(30min ‒ 60min)、OSの種類に限定されてしまう問題がある >> OSの種類を自由にするには、やはり、OS Imageのwhole image writeでOSが展開できることが求められる

•  OpenStack Juno以降で、IPA(Ironic Python Agent)による、whole image writeができるようだ

Example) rackspace: OnMetal >> ネットワーク構成が、GMO AppsCloudと似ている

•  その検証について、今現在進行形の内容をここから紹介します

29

第1回 OCDET ベアメタルWG 勉強会

GMOインターネットシステム本部　高田真澄, 柳匡哉

1.  Ironic触ってみて 2.  ローカルブートできんの？

3.  Swift使わないようにできる？

目次

30

1.  Ironic触ってみて

# yum install openstack-packstack # yum install openstack-ironic-api openstack-ironic-common openstack-ironic-conductor

☆ OSは、ubuntu14.0.4　と Centos 7を選択 ☆ Ironicドライバーは、pxe_ssh ☆ 空VMをBaremetalサーバーと見立て検証開始！

■ コンポーネントインストール (CentOS7の場合)

■ 検証環境ネットワーク設定

・ブリッジはDevstackを真似てOpen vSwitchを採用 ⇒ Devstackのセットアップログを探ること数日、見えてきた全容 ⇒ いろいろ設定足りてないなー

・サクッとyumでpackstackとironicをインストール

31

tftp-serverからBareMetal遠いな～

32

[1] 初期起動用ramdiskイメージ準備 # ./bin/ramdisk-image-create ubuntu deploy-ironic -o ubuntu-ramdisk [2] qcow2イメージ作成 # ./bin/disk-image-create fedora -o fedora.qcow2 [3] vmlinuz&initrd 作成（cent7はbusyboxがrepositoryに無い為エラーに) # ./bin/disk-image-get-kernel -d ./ -o fedora -i ./fedora.qcow2

■ イメージ準備

　・イメージの準備にはdiskimage-builderを採用　・pxe系ドライバーには、以下コマンドで作成される5つのイメージが必要

■ 空VM準備

　・空VMの準備はvirt-installで行い、必要箇所をxml直接編集　・ –pxeでネットワークブートを指定

virt-install --connect qemu:///system --name baremetalbrbm_0 --vcpus=1 --ram 1024 \ --disk path=/var/lib/libvirt/images/baremetalbrbm_0.qcow2,bus=virtio,size=12,cache=writeback \ --network network=brbm,model=virtio --pxe \ --os-type=linux --boot network,menu=off --noautoconsole --nographics

33

■ tftp-server設定

　・tftp-serverをIronicに適した形でconfig （重要箇所抜粋) ● yumでインストール # yum install tftp-server syslinux-tftpboot tftp ● iptables設定 # iptables -I INPUT 6 -p udp -m udp --dport 69 -m comment --comment "tftp server" -j ACCEPT ● カーネルモジュール読み込み(snat経由のtftp接続対応) # modprobe nf_conntrack_tftp # modprobe nf_nat_tftp ● map-file準備 (このファイルで、Ironicからノード毎のconfigに読み換えている） # cd /var/lib/tftpboot # vi map-file

■ iSCSI確認

　・iscsidが動いていればiscsiは停止していてよいっぽい。

● ステータス # systemctl status iscsid ● ノード # ls -la /var/lib/iscsi/nodes/

34

■ Baremetalデプロイ時に遭遇したエラー

Filter RamFilter returned 0 host ⇒ ironic用ノードが正常に登録されていないことが原因 ⇒ Power StateがOffのノードがあることを確認 waiting for callbackステータスから進まない ⇒ ironicデプロイはdhcp, tftpboot, iSCSI等openstack外の要素が多々 ⇒ tcpdumpや/var/log/messagesを参考にエラー対応 tftpd: read: Connection refused ⇒ nat越しにtftpのポートに接続できないことが原因 ⇒ iptablesにip_nat_tftp, ip_conntrack_tftpモジュールロード deployingステータスから進まない ⇒ OSイメージ書き込み処理に時間がかかっているか、処理が停止している ⇒ VMのコンソールを確認し、どの部分で止まっているか確認 ⇒ デプロイイメージ自体が問題の可能性あり ubuntu14.0.4でiSCSIターゲットマウント不可 ⇒ CentOS7では発生しなかった為、残りの検証作業はCentOS7を採用

35

２．ローカルブートできんの？・pxe系ドライバーはサーバー再起動時等、常にネットワークブート　⇒ agent_ipmitoolドライバーで検証開始！

■ 構成変更ポイント

・ vxlan⇒flat構成に変更・ DHCPはNamespaceを使わずブリッジ直結・ glanceのバックエンドにswiftを利用しtemporaryイメージダウンロードurl発行可能に

[1] Ironic Python Agentを含むRmadisk作成 (Fedoraベース） # ./bin/disk-image-create -a amd64 fedora ironic-agent disable-selinux local-config -o ipa-deploy [2] CentOS7 qcow2イメージ作成 # ./bin/disk-image-create -a amd64 centos7 vm dhcp-all-interfaces disable-selinux local-config -o centos7.qcow2

■ イメージ準備

・必要なイメージがpxe系のドライバーと異なる・ ‘Ironic Python Agent’をデプロイ時のRamdiskに仕込む必要あり・現状、Ironic Python Agentのエレメントはfedoraにしか対応してない・ qcow2イメージ作成は、エレメント‘vm’を付与しないとローカルブート失敗

36

■ 構成イメージ

37

■ ひたすらエラー回避の道のり

Permission denied: '/tftpboot/... ⇒ 凡ミスw tftp_rootにironicに書き込み権限があるか確認 IPA動いて無いよ ⇒ これはバグ、作成したRamdiskでIPAはインストールされているが、startしていない状況、 diskimage-builderのスクリプト修正で対応 DHCP関連 ⇒ DHCPセグメントはNative vlanで設定されているか ⇒ BareMetalサーバーが登録したMACのインタフェースでDHCP取得を行っているか PXE関連 ⇒ tftpサーバーがDHCPセグメントに設定されているか(⇒ironic.conf tftp_server) ⇒ dnsmasqのoptsファイル確認

38

'Connection aborted.', error 113, 'No route to host' ⇒ BaremetalサーバーからSwiftへ接続できていないことが原因。 ⇒ DHCPセグメントのラインがSwiftサーバーに設定されているか確認。 ⇒ ironic.confのswift_endpoint_url確認 ImageDownloadError ⇒ swiftには接続できたが、認証エラー、 tmp_url設定が原因デプロイ後またPXEブート ⇒ qcow2のイメージにMBRが書き込まれていないことが原因でHDDより起動できずPXEブートをしている。MBRが書き込まれたqcow2イメージを準備する。 cloud-init走らない ⇒ Baremetalサーバーからneutron-metadata-agentのルーティングの問題 ⇒ dnsmasq 設定確認、gatewayがironicになっているか。

■ 苦労したけど…

☆ ローカルブート可能！ ☆ お！Windowsのデプロイ可能！

39

３．Swift使わないようにできる？ ⇒ディフォルトでは対応していないのでソースの改修が必要

1st ocdet baremetal mtg openstack baremetal compute by gmo appscloud

Technology