[Note]運用RDO 建立OpenStack基本架構
其實也拖快要一年多了，終於可以靜下心寫一下以前利用RDO建立Openstack環境的筆記。
所以.....直接進入正題。
因為RDO本身就是利用Redhat/CentOS自有的YUM 系統為基礎，透過Internet下載建立OpenStack 需要的RPM 套件，並且透過RDO事先轉寫好的腳本進行本機端安裝以及設定。其實先期準備中，最讓人頭大的應該就是RDO本身的設定檔，因為只要一步錯、就是步步錯....。
在我的規劃當中，除了基本的GUI界面管理之外，讓VM啟動、存取storage以及存放image的services，都是基本的。加上OpenStack 的Orchestration功能，所以歸納出需要的服務：
1. Horizon - WebGUI service;
2. Keystone - authentication;
3. Nova - compute service;
4. Cinder - Volume (storage) service;
5. Neutron - network service;
6. Glance - image service;
7. Heat - Orchestration;
8. Celiometer - data collection service;
在早期的Openstack架構當中，是沒有專門的network service，但當VMs 規模越來越大、需要自動化佈署以及集中化的網路管理系統，才使Neutron應運而生。如果要朝SDN相關的研究，或許採用Neutron network架構會比傳統的 Legacy-Nova network來得更容易管理網路架構（當然，前提示整體規模要夠大....）。
接下來則是規劃需要幾台機器，我用了四台伺服器 ─ 兩台1P、兩台2P伺服器（其實這部份還是要看預算，畢竟伺服器真的不便宜、但是真的耐用...如果買口碑好一點的話....），一台1P用來連結Internet用的跳板機，另外一台1P用於Controller，另外兩台作為Nova service（其中一台作為Cinder service with gluster FS）。
接下來就是規劃需要的一些基本要件（軟體部份）：
1. 基礎OS : CentOS 7;
2. OpenStack 自動化安裝程式：RDO，based on RPM package system;
3. EPEL：這將會提供許多基礎CentOS套件庫沒有、但卻是OpenStack需要的套件；
4. GlusterFS : 用在volume creation;
5. NIC port x2：用於tunnel 以及management;
然後，就該是開始進行一些比較細節的設定了。
首先、先安裝CentOS 7，並且選擇有虛擬功能的相關套件選項。安裝並且做完基本設定之後，再以root登入，我們還要增加EPEL以及OpenStack套件庫。EPEL在全球都有mirror site，而RDO的套件庫可以在Fedora project尋找到相關資源。
考量到OpenStack 擁有自己的機制，我們會事先停止CentOS 7 內建的firewalld以及NetworkManager（用network.service來替代）。另外，因為OepnStack 需要認得每個伺服器的hostname，所以跟hostname的設定也應該要先做好，而我自己也先disable SELinux，以防不必要的安裝錯誤發生（不過原廠安裝文件倒是沒提到.....）。
另外，安裝GlusterFS的相關套件以及packstack這個接下來自動化安裝OpenStack的工具，也是一定要事先作好的。
接下來，筆者打算就直接將主要的設定步驟、用條列方式列出：
1. In the Controller host, generate the "answer file":
packstack --gen-answer-file=[filename]
2. Modify some variables in the answer file:
– CONFIG_CONTROLLER_HOST=[IP Addr. of the controller]
– CONFIG_COMPUTE_HOSTS=[IP Addr. of nova1],[IP Addr. of nova2]
– CONFIG_NETWORK_HOSTS=[IP Addr. of the Neutron controller]
– CONFIG_CINDER_BACKEND=gluster <== 我們採用GlusterFS
– CONFIG_CINDER_GLUSTER_MOUNTS=[IP Addr. of the storage]:/glu1 ← our glusterFS folder
– CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=[physnet1]:ovsbr1, [physnet2]:ovsbr2 ← 採用OVS作為Neutron核心套件，"physnet1/2"指的是實體網路連接埠
– CONFIG_NEUTRON_OVS_BRIDGE_IFACES=ovsbr1:[physnet1],ovsbr2:[physnet2]
– CONFIG_NEUTRON_OVS_TUNNEL_IF=ovsbr2 ← We use ovsbr2 as tunneling intereface
– Change all password if needed
在調整好需要的參數之後，我們利用改好的answer file，作一次正式的full run:
packstack –answer-file=[修改好的answer file]
接下來，我們會看到packstack程式開始透過網際網路抓取各個OpenStack 所需要的service，並且進行安裝以及細部設定。這邊先不寫GlusterFS如何設定，留待之後再寫。如果在佈署過程出現錯誤，務必到 /var/log/ 下面查看問題點在哪裡。
佈署完成之後，重開所有SUT，以確保所有機器中的services都如預期中地啟動。
接下來，回到原先設定controller的機器，我們會看到在/root/下有一個keystonerc_admin的檔案，這檔案是admin相關的環境變數，請務必先匯入：
source /root/keystonerc_admin
接下來，我們就可以在遠端登入controller的Horizon service提供的webGUI界面了。
如我們所見，基本的webGUI登入之後，可以看到所有的instance (guestVM) 會包侷限在private network裡面，public 跟 private 之間會有一個neutron service 創建的router存在著。如果要讓內部的instance能被public網段存取，則需要新增一組floating IP給予instance，就可以利用像是ssh等remote service進行存取。當然，OpenStack也不僅僅只有這個feature，像是Heat -- OpenStack 下的orchestration service，也是NFV架構下所希望擁有的feature。雖然還不是很熟悉這個service的威力，但是對於大量佈署的使用者而言，Heat service的確是一項利器。
其實只是完成了基本的OpenStack架構，但若要真的應用在實際的層面，恐怕還是需要更多實務經驗、才能有一個更清晰的NFV/SDN 藍圖。
所以.....直接進入正題。
因為RDO本身就是利用Redhat/CentOS自有的YUM 系統為基礎，透過Internet下載建立OpenStack 需要的RPM 套件，並且透過RDO事先轉寫好的腳本進行本機端安裝以及設定。其實先期準備中，最讓人頭大的應該就是RDO本身的設定檔，因為只要一步錯、就是步步錯....。
在我的規劃當中，除了基本的GUI界面管理之外，讓VM啟動、存取storage以及存放image的services，都是基本的。加上OpenStack 的Orchestration功能，所以歸納出需要的服務：
1. Horizon - WebGUI service;
2. Keystone - authentication;
3. Nova - compute service;
4. Cinder - Volume (storage) service;
5. Neutron - network service;
6. Glance - image service;
7. Heat - Orchestration;
8. Celiometer - data collection service;
在早期的Openstack架構當中，是沒有專門的network service，但當VMs 規模越來越大、需要自動化佈署以及集中化的網路管理系統，才使Neutron應運而生。如果要朝SDN相關的研究，或許採用Neutron network架構會比傳統的 Legacy-Nova network來得更容易管理網路架構（當然，前提示整體規模要夠大....）。
接下來則是規劃需要幾台機器，我用了四台伺服器 ─ 兩台1P、兩台2P伺服器（其實這部份還是要看預算，畢竟伺服器真的不便宜、但是真的耐用...如果買口碑好一點的話....），一台1P用來連結Internet用的跳板機，另外一台1P用於Controller，另外兩台作為Nova service（其中一台作為Cinder service with gluster FS）。
接下來就是規劃需要的一些基本要件（軟體部份）：
1. 基礎OS : CentOS 7;
2. OpenStack 自動化安裝程式：RDO，based on RPM package system;
3. EPEL：這將會提供許多基礎CentOS套件庫沒有、但卻是OpenStack需要的套件；
4. GlusterFS : 用在volume creation;
5. NIC port x2：用於tunnel 以及management;
然後，就該是開始進行一些比較細節的設定了。
首先、先安裝CentOS 7，並且選擇有虛擬功能的相關套件選項。安裝並且做完基本設定之後，再以root登入，我們還要增加EPEL以及OpenStack套件庫。EPEL在全球都有mirror site，而RDO的套件庫可以在Fedora project尋找到相關資源。
考量到OpenStack 擁有自己的機制，我們會事先停止CentOS 7 內建的firewalld以及NetworkManager（用network.service來替代）。另外，因為OepnStack 需要認得每個伺服器的hostname，所以跟hostname的設定也應該要先做好，而我自己也先disable SELinux，以防不必要的安裝錯誤發生（不過原廠安裝文件倒是沒提到.....）。
另外，安裝GlusterFS的相關套件以及packstack這個接下來自動化安裝OpenStack的工具，也是一定要事先作好的。
接下來，筆者打算就直接將主要的設定步驟、用條列方式列出：
1. In the Controller host, generate the "answer file":
packstack --gen-answer-file=[filename]
2. Modify some variables in the answer file:
– CONFIG_CONTROLLER_HOST=[IP Addr. of the controller]
– CONFIG_COMPUTE_HOSTS=[IP Addr. of nova1],[IP Addr. of nova2]
– CONFIG_NETWORK_HOSTS=[IP Addr. of the Neutron controller]
– CONFIG_CINDER_BACKEND=gluster <== 我們採用GlusterFS
– CONFIG_CINDER_GLUSTER_MOUNTS=[IP Addr. of the storage]:/glu1 ← our glusterFS folder
– CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=[physnet1]:ovsbr1, [physnet2]:ovsbr2 ← 採用OVS作為Neutron核心套件，"physnet1/2"指的是實體網路連接埠
– CONFIG_NEUTRON_OVS_BRIDGE_IFACES=ovsbr1:[physnet1],ovsbr2:[physnet2]
– CONFIG_NEUTRON_OVS_TUNNEL_IF=ovsbr2 ← We use ovsbr2 as tunneling intereface
– Change all password if needed
在調整好需要的參數之後，我們利用改好的answer file，作一次正式的full run:
packstack –answer-file=[修改好的answer file]
接下來，我們會看到packstack程式開始透過網際網路抓取各個OpenStack 所需要的service，並且進行安裝以及細部設定。這邊先不寫GlusterFS如何設定，留待之後再寫。如果在佈署過程出現錯誤，務必到 /var/log/ 下面查看問題點在哪裡。
佈署完成之後，重開所有SUT，以確保所有機器中的services都如預期中地啟動。
接下來，回到原先設定controller的機器，我們會看到在/root/下有一個keystonerc_admin的檔案，這檔案是admin相關的環境變數，請務必先匯入：
source /root/keystonerc_admin
接下來，我們就可以在遠端登入controller的Horizon service提供的webGUI界面了。
如我們所見，基本的webGUI登入之後，可以看到所有的instance (guestVM) 會包侷限在private network裡面，public 跟 private 之間會有一個neutron service 創建的router存在著。如果要讓內部的instance能被public網段存取，則需要新增一組floating IP給予instance，就可以利用像是ssh等remote service進行存取。當然，OpenStack也不僅僅只有這個feature，像是Heat -- OpenStack 下的orchestration service，也是NFV架構下所希望擁有的feature。雖然還不是很熟悉這個service的威力，但是對於大量佈署的使用者而言，Heat service的確是一項利器。
其實只是完成了基本的OpenStack架構，但若要真的應用在實際的層面，恐怕還是需要更多實務經驗、才能有一個更清晰的NFV/SDN 藍圖。