Multiple Neutron external network on one node

In order to achieve multiple external networks in Neutron, where each external network has different subnet and default gateway, we need multiple L3 agents. Note: this is only for Havana and below, since Change Id260a239 (developed in Icehouse cycle) multiple external networks can be handled by single l3-agent.

Official documentation has cover on this, I will cover much detail in this article.

Besides br-ex you originally have, we need to create a new OVS bridge br-ex-2, then add the physical interface connected to that external network to br-ex-2.

If there is IP address already associated with that physical interface (eth3), you need to clear it with:

# ip addr del x.y.z.w dev eth3

Create the bridge and add the port:

# ovs-vsctl add-br br-ex-2
# ovs-vsctl add-port br-ex-2 eth3

Same as when you configured br-ex , configure /etc/network/interfaces like this:

# We need the section below or eth3 will not be up on boot
auto eth3
        iface eth3 inet manual
        up ifconfig $IFACE 0.0.0.0 up
        up ip link set $IFACE promisc on
        down ip link set $IFACE promisc off
        down ifconfig $IFACE down
# br-ex-2 should have a IP belongs to that external subnet, default gateway should not be needed, since you already have br-ex
auto br-ex-2
iface br-ex-2 inet static
        address x.y.z.w
        netmask 255.255.255.0
        network x.y.z.0
        broadcast x.y.z.255

Each l3-agent has respective l3_agent.ini:

# l3_agent.ini
[DEFAULT]
host = network
external_network_bridge = br-ex
metadata_port = 8775
gateway_external_network_id = 9de13fee-fdcf-4343-9a8b-9f04deaf0d41 # Your external network id obtained via neutron net-list
router_id = 046c79ed-64f3-40ce-9328-f8b6329e81f4 # Your external router ID obtained via neutron router-list
# OVS
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
# l3_agent-2.ini
[DEFAULT]
#debug = True
host = network-psuedo2
external_network_bridge = br-ex-2
metadata_port = 8775
handle_internal_only_routers = False
gateway_external_network_id = cc4ad4e0-e86e-43cf-bcd8-36de71be8b01
router_id = 6e9cc927-73ba-40e4-8d2e-e2a8fca24280
# OVS
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

The host directive distinguishes multiple l3-agents, or they’ll be recognized as the same agent in Neutron.
Also add network-psuedo2 to /etc/hosts , point to the IP address you set on br-ex-2:

x.y.z.w      network-psuedo2

Now just start the agent in commandline:

# /usr/bin/python /usr/bin/neutron-l3-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent-2.ini --log-file=/var/log/neutron/-agent-2.log

Note: I’m not sure if there’s any risk running l3-agent as root, but I have yet to figure out a way to run it as the neutron user. You can also combine nohup tool.

Deploy OpenStack with Chef, Part 2: Network

In this part we’ll set up the network node, Neutron plugins and create base Neutron networks. Rackspace’s documentation to set up Neutron was confusing to me, so I checked the official OpenStack Documentation and figured out some things need to be done differently from Rackspace’s documentation.

Set up br-ex

Execute commands in this section on the network node.

After the chef-client run on network node finishes, br-ex is created, we need to manually add our external interface to br-ex, during the procedure the external network connectivity will be lost so it’s a good idea to SSH into network node via its private IP (In my case 172.17.1.5), also just in case that external network never get back up.

Remove IP address on eth0 because we want to add it to a bridge. Network connectivity on eth0 will be lost. I learned this command here.

# ip addr flush dev eth0

Add eth0 to the bridge br-ex

# ovs-vsctl add-port br-ex eth0

Assign public IP to br-ex and add default gateway

# ifconfig br-ex inet x.y.54.54 netmask 255.255.255.0
# route add default gw x.y.54.254

Now you can verify if external connectivity works. If not, check your routing table, mine looks like this:

0.0.0.0         x.y.54.254      0.0.0.0         UG        0 0          0 br-ex
140.113.54.0    0.0.0.0         255.255.255.0   U         0 0          0 br-ex
172.17.1.0      0.0.0.0         255.255.255.0   U         0 0          0 eth1

Edit /etc/network/interfaces as my example to make these settings persistent.

Create base Neutron networks

Execute commands in this section on the controller node.

Mostly the same as official OpenStack documentation.

Read credentials:

# source ~/openrc

Create net network:

# neutron net-create ext-net --router:external=True \
  --provider:network_type gre --provider:segmentation_id 2 --shared

Create subnet for ext-net:

# neutron subnet-create ext-net --allocation-pool start=x.y.54.1,end=x.y.54.10 \
  --gateway=x.y.54.254 --enable_dhcp=False x.y.54.0/24

Create router:

# neutron router-create ext-to-int

Connect the router to ext-net by setting the gateway for the router as ext-net:

# neutron router-gateway-set EXT_TO_INT_ROUTER_ID EXT_NET_ID

Create internal network and subnet:

# neutron net-create admin-net
# neutron subnet-create admin-net 192.168.2.0/24 --gateway 192.168.2.1

Connect the internal subnet to router:

# neutron router-interface-add EXT_TO_INT_ROUTER_ID INTERNAL_SUBNET_ID

Update internal subnet’s DNS information:

# neutron subnet-update INTERNAL_SUBNET_ID \
  --dns_nameservers list=true 8.8.8.8 8.8.8.7

Now you can boot up an instance, select the interface to admin-net, and see if it gets IP and DNS settings correctly.

Deploy OpenStack with Chef, Part 3: Storage

Cinder needs a LVM volume group to create volumes. Make sure you have free space on the VG (on storage node):

# vgdisplay
  --- Volume group ---
  VG Name               storage-vg
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               546.21 GiB
  PE Size               4.00 MiB
  Total PE              139831
  Alloc PE / Size       13824 / 54.00 GiB
  Free  PE / Size       126007 / 492.21 GiB
  VG UUID               MfihR0-9350-o1T9-OQhU-aL2E-RtwA-JO9I7d

If your have no free space left, you can follow this guide to shrink existing partitions (LV).

In the environment file, you can specify which VG cinder should use:

    "cinder": {
      "storage": {
        "lvm": {
          "volume_group": "<VG_name>"
        }
      }
    },

Then on chef server, add the cinder-all role:

# knife node run_list add storage.openstack.xxxx.tw 'role[cinder-all]'

Run chef-client on storage node:

# chef-client -E <environment_name>

Run chef-client on controller node again, since cinder-api and cinder-scheduler run on it:

# chef-client -E <environment_name>

Problems

I encountered a weird problem that cinder services on storage node cannot connect to MySQL on controller. Investigation found that /etc/cinder.conf has wrong mysql password. I copied over mysql password for user cinder from controller’s /etc/cinder.conf and it worked. This is just a temporary fix, I guess it would be overwritten on the next chef-client run, not sure why chef-client gets the wrong password.

Run chef-server and OpenStack controller on same node

Update: This did not end up well so I gave up, actually you can put Chef server anywhere as long as it can be reached by clients, even in another VM would work after some patches to RackSpace scripts.

Chef’s own rabbitmq-server will conflict with OpenStack’s, so I had to configure Chef to use the system rabbitmq.

Use this guide: https://community.rackspace.com/products/f/45/t/1669

Also add
bookshelf['url'] = "https://#{node['ipaddress']}:4000"
to /etc/chef-server/chef-server.rb.

ref: https://groups.google.com/forum/#!topic/opscode-chef-openstack/0DnbYhxQT90

鳳梨酥計劃:FreeBSD on OpenStack

最近都在交大計中內玩 OpenStack 相關的事情。

FreeBSD 是我架伺服器的首選,令人意外的是要在 OpenStack 上面跑 FreeBSD 到現在依然都還沒有很好的方案…

CNMC 和交大計中都大量使用 FreeBSD ,同時我們也在研究 OpenStack ,在 OpenStack 上跑 FreeBSD 能提供我們很多好處。同時,身為 FreeBSD 的使用者和支持者,當然希望更多人來使用,也擔心現在很多的使用狀況都是在 VM 裡頭,如果 FreeBSD 沒辦法在雲端環境下運行,就是多了使用上的限制,不利於 FreeBSD 的普及。

因此我,Iblis 和 Apua ,決定開始計劃來讓 FreeBSD 像各種 Linux 一樣在 OpenStack 環境下輕鬆順利的部署和運行。我們將計劃命名為鳳梨酥計劃!(這個名字讓我們笑了很久,會取這個名字是因為使用來自台灣的東西更可以凸顯這個計劃的發源)

鳳梨酥計劃基本上就是給 FreeBSD 用的 cloudinit

計劃分為兩大部分。一為 instance 的開機腳本,會在開機時讀取 OpenStack 的各種環境變數並依照環境變數來設定 instance ,這部分稱為 bsd-cloudinit ,做的事情和 Linux 上面的 cloudinit 相近。第二部分為 VM template 化腳本,在建立 template 的時候使用,負責移除 VM 的各種特徵,如 SSH host key ,以免屆時開新 instance 的時候 VM 的特徵重複。除此之外還要負責安裝 bsd-cloudinit ,我們將第二部分稱為 bsd-cloudinit-installer

命名

會開始做這件事情是想說,這件事情應該很簡單,但是卻沒有人做(我也很納悶為什麼沒有人做)。在 FreeBSD 上面做各類的系統管理只要用 CLI 就可以完成,我們要做的事情只是把外面的資訊拉進來,和這些動作黏在一起,就做完了。

剛開始我們就確立了一個方向,就是不要管 code 有多髒,能動就好。後來覺得這真的是正確的決定。由於不管架構、維護性等問題,我們很快就做出基本的功能。快速做出基本功能有一個重要的好處就是可以迅速獲得進度的回饋(你看,我們這麼快就做出這個功能了!),有進度就產生成就感,成就感對於計劃的繼續進行我認為很重要。要是我們顧慮很多,拖了很久還做不出第一個功能,因為沒有明顯的進度,心理上就很難產生成就感,很可能連第一個功能都沒做出來就不想做了。

計劃的命名也讓我們想了很久和笑了很久,剛開始我們提了一堆希臘神明之類的名字(因為拼起來很酷XD)。可是其實我一直覺得開源計劃的名稱應該要達到幾個目的:能夠顯示計劃的緣起、計劃的功能、好念、好記,再來還要看起來很酷很先進。

計劃剛開始我只有找 Iblis ,那天我給 Iblis 做 OpenStack 架構的簡報,Apua 走進來問我們要幹嘛,我就簡單講了一下然後附帶問了一句「要不要加入」,然後 Apua 就加入計劃了www

第一天我們就開始想名稱了哈哈,剛開始想了一堆希臘神明的名字,那天我剛好有帶鳳梨酥當點心,靈機一動就提出用鳳梨酥當名字XDD

鳳梨酥這名字超棒,首先,它顯示了我們的起源——台灣,只有台灣有這種點心。再來,它好念而且念起來很酷(對於不會中文的人而言),想像一個老外說 “feng li su" 的聲音XD

但是為了顯示計劃目標,我們還是再加了一個附標題:bsd-cloudinit

開發過程

幾乎都是以半 hackathon 的方式進行的,我們大概花掉幾個週末和平日晚上吧。

Iblis 負責用各種骯髒的方法用 shell script 實作各種動作,因為我們兩個都不會寫 Python ,Apua 提供 Python 支援,幫我了解 cloudbase-init 的架構,我比較了解 OpenStack 和 cloudinit 的架構,所以我要提供其他人方向,還有架構用以前弄好的 OpenStack 提供測試環境,還有負責 build template 、寫文件、去 mailing list 宣傳什麼的。

我們三人的領域都不太相同,但都互相稍微了解對方的領域。合作起來很愉快的一點就是一旦遇到問題就可以互相回答,像是不確定要用哪種實作的時候馬上就有人可以討論、分析和決定。不像我常常自己寫程式寫到一半沒辦法決定 implementation 就整個卡在那邊猶豫很久,要是猶豫太久就會開始打混了XD

成果

我們的計劃被加進 OpenStack Image Guide 了!超爽

下一步

最大的重點就是把 cloudconfig 的功能加進去,這樣才是真的自動化啊。

還有很多很髒的的地方要稍微修一修⋯⋯

鳳梨酥計劃主網站及說明文件

VMware vSphere / XenServer 和 OpenStack / OpenNebula 到底有什麼差別

最近看了一些 OpenStack Summit 演講的影片,尤其是 Moving From Virtualized Infrastructure to OpenStack ,對於虛擬化和雲端運算又有了更深一層的認識。

影片中提到,vSphere 和 OpenStack 是完全不同的產品。vSphere 是從硬體開始打造雲端,意思是先從硬體、hypervisor 的角度來思考問題,也可以說是從 VM 開始考慮問題,由最基本的 ESXi hypervisor ,往上增加功能到 vCenter (但我只用過 ESXi 沒用過 vCenter ,我只是大概知道 vCenter 有什麼樣的功能),而 XenServer 也是類似的概念。 OpenStack / OpenNebula (這兩個是不同的計劃,但是功能、概念接近)則是從完全不同的出發點來考慮問題,OpenStack 是從應用程式本身(的需求)出發,對於應用程式來說,幾個 VM 、幾個 host 並不是重點,重點是怎麼讓應用程式不中斷的運行。

在 vSphere 的環境中,首先是建置 ESXi ,然後在上面一臺一臺的安裝 VM 、然後設定 VM 的網路、安裝應用程式的環境,這部分就跟沒有虛擬化的情形下買一臺伺服器然後安裝的過程一樣,維護應用程式的方式也是和從前沒兩樣,遠端至 VM 裏面和以前一樣進行升級等等的操作。唯一比以前更方便的地方大概就是 live migration ,單一伺服器的硬體維護或是故障不影響 VM 的運行。 vCenter 就多了一些更高階(意思是更抽象化,就是從比較大規模的觀點來看看可能的問題)的功能,這些功能在小規模的環境當中(<10 VM)很可能用不到,像是 High availability, fault tolerance 等等,小規模的環境中就算沒有這些功能,這些應用程式的可用性對於這樣小規模的組織可能也已經夠用。

有沒有注意到,整個 vSphere 環境考慮的主體是 VM ,而不是 Application ,vSphere 的重點是讓 VM 不中斷的運行,對於更上層的 Application ,它其實不太在乎。這樣的好處是,以往的應用程式 (Legacy Application) 很可能並沒有把雲端技術納入應用程式的設計當中,像是沒有考慮 scaling 問題,scaling 的能力大多依賴伺服器端軟體、作業系統的效能調校和底層硬體 (VM) 的效能(這個概念稱作 Scalue up ,把處理能力向上提升)。因此就算你在雲端的環境當中部署了這樣的 Legacy application ,很多雲端環境所提供的功能也是用不到的,而且在雲端環境上做 legacy application 的維護我覺得 overhead 還蠻大的,雲端環境本身的維護我覺得也需要更多的心力。(我覺得 ESXi 本身的維護比 OpenStack / OpenNebula 還要簡單)。

虛擬化是雲端運算的基礎,但是做到虛擬化並不等於做到雲端。vSphere 這樣的產品應該是定位爲虛擬化基礎架構 (Virtual Infrastructure) 而非雲端基礎架構 (Cloud Infrastructure, Infrastructure as a Service) 。

OpenStack / OpenNebula 是以應用程式爲出發點的解決方案,是從比較高階(遠離硬體層面)、比較大規模的觀點來考慮,所以建 VM 的方式不是像 ESXi 這樣一次新增一個 VM 慢慢調硬體參數(當然 vCenter 也有 template 的功能),而是必須使用固定的硬體樣板 (template, OpenStack 稱作 flavor) ,這樣一來對於小規模的環境反而是造成了不便,因爲每個 Application 可能就只有一臺 VM 而已,若是每個應用程式的需求不同,每個 VM 要使用不同的樣板,那這樣也失去樣板的意義了。但是在大規模的環境中這樣就會很方便,當要一次部署10, 20臺一模一樣的 VM 時,樣板就會派上用場了。在部署 VM 的時候每臺 VM 應該要不同的參數也可以由雲端環境插入,像是 IP 、 MAC 、hostname ,雲端環境也會記錄這些資訊,比起 vSphere ,OpenStack 更瞭解 VM 的狀況。

OpenStack 以應用程式爲出發點,但是它考慮的主要是雲端應用程式 (Cloud application) 或是說 cloud-aware application (在這邊 PaaS 或是 SaaS 應該也都可以算是 cloud application),這些應用程式比較瞭解他們所運行的雲端環境,可以跟環境做溝通(透過環境提供的 API ),並且瞭解自身的運作狀況(負載),雲端應用程式的架構上也比較分散,這樣要進行應用程式 capacity (可負載量)會比較方便。雲端應用程式要做 scaling 也很容易,負載量提升時,只要呼叫基礎架構 API 多部署幾臺後端伺服器,整個服務的 capacity 就提升了。呼叫基礎架構 API 的工作可以由其他偵測程式偵測這個應用程式的需求並呼叫來達成,或是,在最佳狀況中,由應用程式本身進行呼叫。ESXi (或 vCenter)的 API 似乎是比較弱的(若有錯請更正我),應用程式要進行呼叫也比較不方便。至於 legacy application 在這樣的環境當中如同前面所提到,就沒有這麼大的好處。

雲端基礎架構的另一個好處是由於近乎統一的 API ,雲和雲之間便可以有連結。像是當你的 application 負載已經超過你整個設施所能負載的量時,應用程式可以透過(幾乎)一樣的 API 對其他提供公開服務的雲端基礎架構設施(公共雲)進行呼叫,把一部分的負載量轉移到公共雲或是你自己的另一朵私有雲。(當然這個過程也有很多問題要考慮)

所以,在一般中小企業、學校當中大多使用的還是 vSphere 這一點,其實也頗爲合理,畢竟規模小,運行的應用程式也是以 legacy application 爲多(因爲要重新開發功能一樣的雲端應用程式成本太高吧)。

至於一個我長久以來的問題:有沒有完全 opensource 的解決方案可以取代 vSphere ? 我目前找到最好的是 Proxmox VE

若是有任何錯誤歡迎在下面留言討論。

參考:http://www.mirantis.com/blog/cloud-prizefight-vmware-vs-openstack/