第39回OpenStack勉強会の資料です。

1. 〜ライブデモを添えて〜

2. 社内検証環境での利用事例を紹介
現在、私がJuniperでの検証環境の
管理をしている中でMAASを導入して
幸せになった話(多分)

3. 現場で起こる「リアル」な問題…
NICのConfiguration問題「NWに繋がりません！！」
-> BondingのConfigurationが抜けていた
セグメント分からない問題「使えるセグなんだっけ？？」
-> 管理表みてください -> 「管理表どこですか？？」
サーバーが増える問題「ほら、これが君の欲しがったサーバーだよ^^」
-> 増えるのめんどくさい。。。(嬉しいんですけどね)
壊れているかもしれない問題「ブートしないんだけど。。。」
-> Boot optionが間違っていました〜！

4. 現場で起こる「リアル」な問題…
サーバー勝手に移動問題「自分の環境で使いたいんで、動かしました」
-> 戻すのが非常にめんどくさい
IP重複問題「IPが重複しています！」
etcetc…

5. 現場で起こる「リアル」な問題…
NICのConfiguration問題「NWに繋がりません！！」
-> BondingのConfigurationが抜けていた
セグメント分からない問題「使えるセグなんだっけ？？」
-> 管理表みてください -> 「管理表どこですか？？」
サーバーが増える問題「ほら、これが君が欲しがったサーバーだ^^」
-> 増えるのめんどくさい。。。(嬉しいんですけどね)
壊れているかもしれない問題「ブートしないんだけど。。。」
-> Boot optionが間違っていました〜！
まぁ、言ってしまえば些細です。
でも、これがたびたびくると。。。

7. 問題解決の糸口
物理的な作業に関する課題は諦める(こればっかりはどうしようもない…)
-> できるだけ汎用的な設計でカバー(SWは手に入れようと思えば手に入るし…)
ソフトウェアで解決できそうな問題は解決させる
-> どういう問い合わせが起こりやすいかを知っていれば対処可能
-> 案外時間を取られるのはドキュメンテーションのアップデート&管理

8. • 些細な問い合わせをできる限り撲滅する
• EXCELを使う様な管理をソフトウェアに任せる
• 手動IPAM & 手動インベントリ管理の撲滅
• サーバが増えた時に素直に喜べる様にしたい

9. 手始めに物理(ポートの収容設計)

10. 手始めに物理(ポートの収容設計)

11. 手始めに物理(ポートの収容設計)
Trunk&Bond
Blank
Access(PXE)

12. 手始めに物理(GWの追加)

13. 超簡単なNW構成図
NAT&Routing
VLAN Switching

21. Ironic API
Ironic
conductor
Ironic DB
Neutron
Nova
Glance

22. Region Controller
- 単一のDatacenterもしくは、regionを管理するコンポーネント
- 複数のFabricを用いることで、一つのregionまたは、
Datacenter内にある複数のフロアなどを表現できる
- DNS,WEBUI,APIを持つ、いわばテナントの様なイメージ

23. Rack Controller
- Datacenter内にあるそれぞれのRackを管理するコンポーネント
- FabricはそれぞれRack Controllerにアタッチされていて、
Network configを提供する
- DHCP,TFTP,HTTP,Power managementを持つ、
スケールアウトアーキテクチャー

24. Fabric
- VLAN Namespaceを定義できる
- デフォルト動作ではMAASが持っているサブネットごとにfabric-xが
作られる
- イメージとしては1fabric = 1 NIC port
- 異なるFabricのVLAN同士であったとしても、疎通が可能な場合は
Spaceとしてグループを作ることができる

28. Apache2
Boot image
tftpd(PXE Boot)
Squid(proxy)
ISC-Dhcpd(DHCP)
Bind (DNS)
Metadata
MAAS WEBUI
rootfs
cloud-init
curtin
squashfs
userdata
metadata
Get http
Write to localdisk
Perform script
PXE Boot
(Diskless)
boot
dd
reboot
Server Client

29. New Commissioning Ready
Commission
Failed
Deploying Deployed
Deploy
Failed
メンテナンスに使う状態は除外版!!

30. New Commissioning Ready
Commission
Failed
Deploying Deployed
Deploy
Failed

37. こ、これは…instack.json

39. New Stateのまとめ
- MAASのリスト(URL)に登録されている
- Specなどの情報は登録されていない
- 電源管理を行うための情報は登録されている
- 自動でつけられる名前は[形容詞]-[名詞].maas
- マシンに振られるIDはMAAS/#/node/[alphabet の7文字]からなる

40. New Commissioning Ready
Commission
Failed
Deploying Deployed
Deploy
Failed

42. Machine summary
- CPU,Mem,Diskの情報が収集されて表示される
- 後述のlogタブを見るとわかるが、lscpuなどを叩いて収集
- Specの情報を元にNodeをscheduleすることも可能に！
- ここはIronicのintrospectionと同じ

44. Interfaces
- デプロイするサーバのNIC configurationが可能
- Bonding, Bridge, VLAN taggingをサポート
- IPAMはDHCP,Staticの他にAuto Assignという神機能がある

47. Network Configuration

48. Network Configuration

49. Network Configuration

50. Network Configuration

51. Ready Stateのまとめ
- Commissioningが終了し、HW情報が登録されている状態
- DeployするOSの基礎的なConfigurationが可能
- 3rd PartyとIntegrationする時はこの状態にしておく
- オーケストレーターがデプロイを実行するため

52. New Commissioning Ready
Commission
Failed
Deploying Deployed
Deploy
Failed
メンテナンスに使う状態は除外版!!

55. Network Configuration(つづき)
Layer 3+4
LACP fast

56. Network Configuration(つづき)

57. Network Configuration(つづき)

58. Network Configuration(つづき)

60. Juju
- VM、Baremetalマシン、Containerのデプロイから
Apllicationのデプロイまでしてくれるオーケストレータ
- JujuとMAASは連携が可能で、OpenStackを簡単にデプロイする
ことが可能！
- CharmというPythonで書かれたPlaybookの様なものを
用いてデプロイする

61. http://www.airshipit.org/

62. http://www.airshipit.org/

63. http://www.airshipit.org/

64. Airship
- コンテナ、ベアメタル、VMをデプロイできる様にしたUCP
- ベースのk8sがあり、その上にMAASとOpenStackが
コンテナでデプロイされる
- AT&TとSK Telecom(とIntel)が開発した模様
- なぜ、Ironicではなかったのかは疑問

67. MAASを導入してどう変わったか？
- 問い合わせが減った！
- MAASの障害対応時間<問い合わせ時間
- NWの作成等もMAASでできるので自分の作った環境をそのまま
利用してくれる様になった！
- とりあえずOSをインストールしてNWにつなぐ！というところが
とても簡単になった！

68. 総括
- 導入が簡単なので気になったら試してみるくらいでも効果が得られる
- TungstenFabricを使っていれば、MAASの環境とVNを統合できる
- ただ、商用で使おうと思うととても苦労をする。。。
- パッケージ、VMイメージ、LXDイメージの固定にかなり苦労する
- MAASは泥臭い作りであるが、相乗りできるシーンはとても多い！