There are many vendors to chose from when selecting your hardware for a complete Openstack deployment (example list of data center friendly networking vendors to look at ). And to make it even more difficult you need to think about all spectrum of vendors like networking, storage and compute.
In one of my previous posts (How to estimate hardware requirements for your private Openstack deployment) I tried to demonstrate an example hardware recommendation for an Openstack deployment. Today we are going to look at this topic once again but exploring the Cisco UCS product line instead.
The data below are taken from the Cisco PDF white paper Red Hat Openstack Architecture on Cisco UCS platform from the DesignZone for Cloud Automation Solution section on Cisco site (http://www.cisco.com/c/en/us/solutions/enterprise/data-center-designs-cloud-computing/could_automation.html).
Openstack on Cisco UCS hardware platform
Cisco is no longer only a networking vendor. With the UCS they offer as well computer platform where you can put together a server with specific hard drive size, mount of RAM or type of CPU, interconnection card etc. An example configuration taken from the Cisco document above:
That means if we put togheter the UCS servers and the Cisco Nexus switches and Openstack software we can build a simple POC like this one:
In the white paper we can actually find a full list of hardware if you would like to build it yourself.
Search This Blog
Showing posts with label openstack. Show all posts
Showing posts with label openstack. Show all posts
Sunday, February 23, 2014
Tuesday, February 4, 2014
Concurrency and parallelism in python
Difference between concurrency and parallelism
The GIL problem is a well know limitation in CPython. Below is on of the video from Heroku conference that shows why this is important (as a bonus you get as well a demo of how to write code in Go language if you want)
The further consequences of this design limitations can be seen in this excellent Mirantis blog post that analyses the performance of an python program: Edge of the Stack: Improve Performance of Python Programs by Restricting Them to a Single CPU.
So what can you do about it? Well until there is GIL in Cpython (and you want or need to stick with this version of python) you may want to chose another library/module for better concurrency support. A long list of available options can be found here: https://wiki.python.org/moin/Concurrency/
At the end to finish up our discussion I can refer you to an practical benchmark that shows a code and do performance analyzes with dealing with concurrency in python: Gevent, Threads, and Benchmarks
The GIL problem is a well know limitation in CPython. Below is on of the video from Heroku conference that shows why this is important (as a bonus you get as well a demo of how to write code in Go language if you want)
The further consequences of this design limitations can be seen in this excellent Mirantis blog post that analyses the performance of an python program: Edge of the Stack: Improve Performance of Python Programs by Restricting Them to a Single CPU.
So what can you do about it? Well until there is GIL in Cpython (and you want or need to stick with this version of python) you may want to chose another library/module for better concurrency support. A long list of available options can be found here: https://wiki.python.org/moin/Concurrency/
At the end to finish up our discussion I can refer you to an practical benchmark that shows a code and do performance analyzes with dealing with concurrency in python: Gevent, Threads, and Benchmarks
Labels:
concurrency,
gil,
mirantis,
multitasking,
openstack,
os,
parallel,
programming,
python
Monday, January 13, 2014
Top Openstack contributors
There is a new site on the main Openstack portal: http://activity.openstack.org/. When looking around to see what information you can find there I stumble upon this post below.
What came as a surprise:
What came as a surprise:
- High position for IBM.
- Not Rackspace or Canonical or Mirantis but Red Hat as a number one contributor.
Labels:
cloud,
openstack,
redhat,
redhat rdo,
statistics
Monday, January 6, 2014
Using Qemu on cloud server to run emulated virtual machines
We know that there is not support for nested hypervisors on cloud instances: Nested virtualization support on Rackspace public cloud.
Problem
How to use Qemu on cloud server and start virtual machine to overcome the nested virtualization limitation.
Demonstration and results description
To overcome this limitation we will use Qemu in its emulated mode. Qemu in this mode doesn't require any specials virtualization support in CPU (HVM - Hardware-assisted virtualization).
The VM image was downloaded from here: http://people.debian.org/~aurel32/qemu/i386/. The default u/p is root.
Alternatively we could use Virtualbox. Although I'm not quite sure what would work better yet and give more options to customizing the VMs.
References
https://wiki.debian.org/QEMU
http://www.linux-kvm.org/page/FAQ - this is more to show what can be missing as the CS don't support KVM
http://en.wikipedia.org/wiki/QEMU
http://www.linuxforu.com/2012/05/virtualisation-faceoff-qemu-virtualbox-vmware-player-parallels-workstation/
Problem
How to use Qemu on cloud server and start virtual machine to overcome the nested virtualization limitation.
Demonstration and results description
To overcome this limitation we will use Qemu in its emulated mode. Qemu in this mode doesn't require any specials virtualization support in CPU (HVM - Hardware-assisted virtualization).
The VM image was downloaded from here: http://people.debian.org/~aurel32/qemu/i386/. The default u/p is root.
Alternatively we could use Virtualbox. Although I'm not quite sure what would work better yet and give more options to customizing the VMs.
References
https://wiki.debian.org/QEMU
http://www.linux-kvm.org/page/FAQ - this is more to show what can be missing as the CS don't support KVM
http://en.wikipedia.org/wiki/QEMU
http://www.linuxforu.com/2012/05/virtualisation-faceoff-qemu-virtualbox-vmware-player-parallels-workstation/
Labels:
cloud,
openstack,
qemu,
rackspace,
virtualisation
Sunday, January 5, 2014
Nested virtualization support on Rackspace public cloud
We have found the CPU hardware architecture that the public cloud is running on in this blog: Hypervisor hardware differences on Openstack Rackspace Cloud.
Problem
Does Rackspace public cloud support nested visualization?
Results discussion
But once the cloud server boots up the cloud virtual CPU no longer exports the hardware CPU virtualization capabilities. You can verify this with this little script below.
That means you can't use your cloud server to run another, a guest hypervisor ( called as well nested hypervisor).
Another solution
If your cloud server doesn't offer nested virtualization support you can always use the emulation mode. Qemu supports running VM that way.
References
http://www.ibm.com/developerworks/cloud/library/cl-nestedvirtualization/
https://www.diigo.com/user/rtomaszewski/nested_virtualization?type=all&snapshot=no&sort=updated
http://en.wikipedia.org/wiki/X86_virtualization
Problem
Does Rackspace public cloud support nested visualization?
Results discussion
- Public Cloud
But once the cloud server boots up the cloud virtual CPU no longer exports the hardware CPU virtualization capabilities. You can verify this with this little script below.
egrep -i 'vmx|svm|ept|vpid|npt|tpr_shadow|flexpriority|vnmi'
That means you can't use your cloud server to run another, a guest hypervisor ( called as well nested hypervisor).
- Private cloud
Another solution
If your cloud server doesn't offer nested virtualization support you can always use the emulation mode. Qemu supports running VM that way.
References
http://www.ibm.com/developerworks/cloud/library/cl-nestedvirtualization/
https://www.diigo.com/user/rtomaszewski/nested_virtualization?type=all&snapshot=no&sort=updated
http://en.wikipedia.org/wiki/X86_virtualization
Hypervisor hardware differences on Openstack Rackspace Cloud
You can spin up test cloud servers and extract CPU flags with the help of this little script using csplit.
By comparing the results we can definitely say that:
cat /proc/cpuinfo | csplit -z - '/processor/' '{*}'
diff xx0*
grep flags xx01 | cut -d ':' -f 2 | xargs -n1 echo | sort > flags.txt
By comparing the results we can definitely say that:
- Performance1 and performance2 cloud servers are running on the same hardware.
- New performance cloud servers are hosted on Intel CPU.
- The standard (next generation) series are being hosted on AMD CPU.
The CPU flags for comparison.
processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : Quad-Core AMD Opteron(tm) Processor 2374 HE stepping : 2 microcode : 0x1000086 cpu MHz : 2200.096 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl pni cx16 popcnt hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch hw_pstate bogomips : 4400.19 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate
processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz stepping : 7 microcode : 0x70d cpu MHz : 2600.068 cache size : 20480 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 43 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt tsc_deadline_timer aes hypervisor lahf_lm arat pln pts dtherm bogomips : 5200.13 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:
Labels:
cloud,
cpu,
hardware,
hypervisor,
openstack,
virtualisation
Saturday, January 4, 2014
Practical online Neutron OVS Lab recording
This is worth re-posting. We learned in the previous post (Openstack Neutron architecture explained based on OVS and VMware NVP plugin comparison (*)) how does the Neutron architecture changes depending what plugins do we use.
In (*) the video #3 walks you through a live lab. Here you can find all the commands run.
https://github.com/rtomaszewski/experiments/blob/master/openstack_neutron_lab
In (*) the video #3 walks you through a live lab. Here you can find all the commands run.
https://github.com/rtomaszewski/experiments/blob/master/openstack_neutron_lab
Labels:
demo,
lab,
neutron,
openstack,
openvswitch,
presentation,
vmware
Openstack Neutron architecture explained based on OVS and VMware NVP plugin comparison
There are 3 recorded meetup videos that were organized by the onlinemeetup Openstack group (http://www.meetup.com/OpenStack-Online-Meetup/). These are an excellent source of information into network virtualization, nova-network, Neutron OVS and NVP plugins.
The recorded sessions can be found on YouTube here:
OpenStack Networking - Theory Session, Part 1
OpenStack Networking - Theory Session, Part 2
OpenStack Networking - Hands-On Lab, Part 3
Network virtualization basic
Nova Networking
The first version of network implemented in Openstack is called nova-networking and can be still used. Some of the advantages and limitations can be seen below.
The most complex deployment architecture used VLANs to implemented tenant and isolation. This scenario has a lot ideas that are then later shared in Neutron plugins.
OVS plugin
As you can see the architecture looks very similar. There are some subtle differences although like: instead of VLAN we use GRE tunnels, instead of Linux bridge we use the OpenVswitch (OVS). The important thing to note is that we don't use OpenFlow protocol to control the OVS switches. The switch will be pre-programmed by the agent running on the hypervisor.
NVP plugin
To describe and explain how NVP works it is good to compare its architecture to OVS plugin above. The first slide shows what component are not being used.
The network communication model with NVP provides new component.
The main differences are:
The recorded sessions can be found on YouTube here:
OpenStack Networking - Theory Session, Part 1
OpenStack Networking - Theory Session, Part 2
OpenStack Networking - Hands-On Lab, Part 3
Network virtualization basic
Nova Networking
The first version of network implemented in Openstack is called nova-networking and can be still used. Some of the advantages and limitations can be seen below.
The most complex deployment architecture used VLANs to implemented tenant and isolation. This scenario has a lot ideas that are then later shared in Neutron plugins.
OVS plugin
As you can see the architecture looks very similar. There are some subtle differences although like: instead of VLAN we use GRE tunnels, instead of Linux bridge we use the OpenVswitch (OVS). The important thing to note is that we don't use OpenFlow protocol to control the OVS switches. The switch will be pre-programmed by the agent running on the hypervisor.
NVP plugin
To describe and explain how NVP works it is good to compare its architecture to OVS plugin above. The first slide shows what component are not being used.
The network communication model with NVP provides new component.
The main differences are:
- OVS switches will be programmed by the NVP cluster using OpenFlow protocol
- Instead of GRE we use STT tunneling
- Security groups will be natively implemented in OVS (no need for iptables)
- The virtual router is highly available and is implemented on external nodes
Labels:
cloud network,
nicira nvp,
openflow,
openstack,
openvswitch,
virtual network
Friday, January 3, 2014
Debugging networking issues in Neutron
Overview of cloud networking and Neutron in Openstack
We saw what challenges a successful Neutron deployment in Openstack would have to overcome in this post: Status and maturity of the Neutron in Openstack Havana release. But the journey into cloud network is worth the trouble and you can find many discussions that show the potential business and technological advantage you gain (an example What your Dev, Engineering and sales teams can achieve by using Openstack cloud and Quantum network).
But as the Neutron continues to bring new and advance networking features with every consecutive Openstack release ( Havana Neutron features) there is always a fear that it may become very complex and difficult to troubleshoot. To help to fill the gap the video from Dave Neary (slides are here Networking in OpenStack for non-networking people) is taking us on the journey what cloud networking and Neutron is as well as showing the basic troubleshooting every one should be aware of.
Neutron troubleshooting
These couple of slides from the video summarized very well what troubleshooting actions you can do when dealing with network connectivity problems from and to your VM. For more info watch the video yourself.
References
http://openstack.redhat.com/Main_Page
http://openstack.redhat.com/Networking
http://openstack.redhat.com/Networking_in_too_much_detail
We saw what challenges a successful Neutron deployment in Openstack would have to overcome in this post: Status and maturity of the Neutron in Openstack Havana release. But the journey into cloud network is worth the trouble and you can find many discussions that show the potential business and technological advantage you gain (an example What your Dev, Engineering and sales teams can achieve by using Openstack cloud and Quantum network).
But as the Neutron continues to bring new and advance networking features with every consecutive Openstack release ( Havana Neutron features) there is always a fear that it may become very complex and difficult to troubleshoot. To help to fill the gap the video from Dave Neary (slides are here Networking in OpenStack for non-networking people) is taking us on the journey what cloud networking and Neutron is as well as showing the basic troubleshooting every one should be aware of.
Neutron troubleshooting
These couple of slides from the video summarized very well what troubleshooting actions you can do when dealing with network connectivity problems from and to your VM. For more info watch the video yourself.
References
http://openstack.redhat.com/Main_Page
http://openstack.redhat.com/Networking
http://openstack.redhat.com/Networking_in_too_much_detail
Wednesday, January 1, 2014
OpenShift PaaS platform from Redhat
We've looked before at AppFog PaaS platform that is leveraging CloudFoundry and Openstack. Today we will investigate the Redhat PaaS alternative, namely OpenShift.
What is OpenShift
OpenShift is a Platform as a Service solution according the the cloud systems taxonomy. It offers a solution, a software development platform that facilitates easy and rapid application development in the cloud.
It can provide a preintegrated software stack environment and can leverage IaaS providers for the virtual infrastructure management (How to Deploy OpenShift Enterprise on Red Hat OpenStack).
A comprehensive presentation that provide further details can be found here: http://rhsummit.files.wordpress.com/2013/06/noceda_t_0120_consumepaasinthecloudwithopenshift.pdf
Demo
What is OpenShift
OpenShift is a Platform as a Service solution according the the cloud systems taxonomy. It offers a solution, a software development platform that facilitates easy and rapid application development in the cloud.
It can provide a preintegrated software stack environment and can leverage IaaS providers for the virtual infrastructure management (How to Deploy OpenShift Enterprise on Red Hat OpenStack).
A comprehensive presentation that provide further details can be found here: http://rhsummit.files.wordpress.com/2013/06/noceda_t_0120_consumepaasinthecloudwithopenshift.pdf
Demo
- Sign in for free account on https://openshift.redhat.com
- Login and from "My App" tab create new application by selecting "Add Application ..." button.
- I've used as simple Python app based on CherryPy framework.
- Once your gear (a Openshift name for your app container) is created you can take a look at the hello world code
- To modify the source code clone the git repo. You will need to first register your public key.
- Generate a new ssh key pair.
$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/rado/.ssh/id_rsa): /tmp/tmp.key $ ssh-agent | tee -a agent.sh SSH_AUTH_SOCK=/tmp/ssh-pMmGGPP15635/agent.15635; export SSH_AUTH_SOCK; SSH_AGENT_PID=15636; export SSH_AGENT_PID; echo Agent pid 15636; $source agent.sh $ssh-add tmp.key Identity added: tmp.key (tmp.key)
- Clone your source repo to modify your app source code.
$ git clone ssh://52c499a1e0b8cdda0f000016@rado-rado1stapp.rhcloud.com/~/git/rado.git/ Cloning into 'rado'... remote: Counting objects: 62, done. remote: Compressing objects: 100% (41/41), done. remote: Total 62 (delta 16), reused 62 (delta 16) Receiving objects: 100% (62/62), 18.93 KiB, done. Resolving deltas: 100% (16/16), done.
- Modify the code to personalize it.
$cd rado/
$ find | grep -v git
./.openshift
./.openshift/markers
./.openshift/action_hooks
./.openshift/action_hooks/README.md
./.openshift/cron
./.openshift/cron/minutely
./.openshift/cron/monthly
./.openshift/cron/weekly
./.openshift/cron/weekly/chrono.dat
./.openshift/cron/weekly/chronograph
./.openshift/cron/weekly/jobs.deny
./.openshift/cron/weekly/README
./.openshift/cron/weekly/jobs.allow
./.openshift/cron/README.cron
./.openshift/cron/daily
./.openshift/cron/hourly
./README.md
./LICENSE
./data
./libs
./wsgi
./wsgi/static
./wsgi/static/README
./wsgi/application
./app.py.disabled
./setup.py
$vim ./wsgi/application
$ cat wsgi/application
import sys
sys.stdout = sys.stderr
import atexit
import threading
import cherrypy
cherrypy.config.update({'environment': 'embedded'})
if cherrypy.__version__.startswith('3.0') and cherrypy.engine.state == 0:
cherrypy.engine.start(blocking=False)
atexit.register(cherrypy.engine.stop)
class Root(object):
def index(self):
return 'Hello from rado 1st app on openshift ;)!'
index.exposed = True
application = cherrypy.Application(Root(), script_name=None, config=None)
- Once you are happy with t he code it is time to push changes back to git and redeploy it inside OpenShift.
$ git commit ./wsgi/application [master 0eccd4d] init 1 file changed, 1 insertion(+), 1 deletion(-) $ git push origin master Counting objects: 7, done. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 393 bytes, done. Total 4 (delta 2), reused 0 (delta 0) remote: Stopping PYTHON cart remote: [Wed Jan 01 17:59:08 2014] [warn] PassEnv variable SHELL was undefined remote: [Wed Jan 01 17:59:08 2014] [warn] PassEnv variable USER was undefined remote: [Wed Jan 01 17:59:08 2014] [warn] PassEnv variable LOGNAME was undefined remote: Waiting for stop to finish remote: Building git ref 'master', commit 0eccd4d remote: running develop remote: running egg_info remote: creating Example_CherryPy.egg-info remote: writing requirements to Example_CherryPy.egg-info/requires.txt remote: writing Example_CherryPy.egg-info/PKG-INFO remote: writing top-level names to Example_CherryPy.egg-info/top_level.txt remote: writing dependency_links to Example_CherryPy.egg-info/dependency_links.txt remote: writing requirements to Example_CherryPy.egg-info/requires.txt remote: writing Example_CherryPy.egg-info/PKG-INFO remote: writing top-level names to Example_CherryPy.egg-info/top_level.txt remote: writing dependency_links to Example_CherryPy.egg-info/dependency_links.txt remote: writing manifest file 'Example_CherryPy.egg-info/SOURCES.txt' remote: reading manifest file 'Example_CherryPy.egg-info/SOURCES.txt' remote: writing manifest file 'Example_CherryPy.egg-info/SOURCES.txt' remote: running build_ext remote: Creating /var/lib/openshift/52c499a1e0b8cdda0f000016/app-root/runtime/dependencies/python/virtenv/lib/python2.7/site-packages/Example-CherryPy.egg-link (link to .) remote: Example-CherryPy 1.0 is already the active version in easy-install.pth remote: remote: Installed /var/lib/openshift/52c499a1e0b8cdda0f000016/app-root/runtime/repo remote: Processing dependencies for Example-CherryPy==1.0 remote: Searching for CherryPy==3.2.4 remote: Best match: CherryPy 3.2.4 remote: Processing CherryPy-3.2.4-py2.7.egg remote: CherryPy 3.2.4 is already the active version in easy-install.pth remote: Installing cherryd script to /var/lib/openshift/52c499a1e0b8cdda0f000016/python/virtenv/bin remote: remote: Using /var/lib/openshift/52c499a1e0b8cdda0f000016/app-root/runtime/dependencies/python/virtenv/lib/python2.7/site-packages/CherryPy-3.2.4-py2.7.egg remote: Finished processing dependencies for Example-CherryPy==1.0 remote: Script /var/lib/openshift/52c499a1e0b8cdda0f000016/python//virtenv/bin/activate.fish cannot be made relative (it's not a normal script that starts with #!/var/lib/openshift/52c499a1e0b8cdda0f000016/python/virtenv/bin/python) remote: Script /var/lib/openshift/52c499a1e0b8cdda0f000016/python//virtenv/bin/activate.csh cannot be made relative (it's not a normal script that starts with #!/var/lib/openshift/52c499a1e0b8cdda0f000016/python/virtenv/bin/python) remote: Preparing build for deployment remote: Deployment id is f17888e7 remote: Activating deployment remote: Script /var/lib/openshift/52c499a1e0b8cdda0f000016/python//virtenv/bin/activate.fish cannot be made relative (it's not a normal script that starts with #!/var/lib/openshift/52c499a1e0b8cdda0f000016/python/virtenv/bin/python) remote: Script /var/lib/openshift/52c499a1e0b8cdda0f000016/python//virtenv/bin/activate.csh cannot be made relative (it's not a normal script that starts with #!/var/lib/openshift/52c499a1e0b8cdda0f000016/python/virtenv/bin/python) remote: Starting PYTHON cart remote: Result: success remote: Activation status: success remote: Deployment completed with status: success
- Final test that all worked fine ;)
$ curl -v -s http://rado-rado1stapp.rhcloud.com ;echo * About to connect() to rado-rado1stapp.rhcloud.com port 80 (#0) * Trying 54.221.76.112... connected > GET / HTTP/1.1 > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 > Host: rado-rado1stapp.rhcloud.com > Accept: */* > < HTTP/1.1 200 OK < Date: Wed, 01 Jan 2014 23:33:20 GMT < Server: Apache/2.2.22 (Red Hat Enterprise Web Server) < Content-Length: 40 < Content-Type: text/html;charset=utf-8 < Vary: Accept-Encoding < * Connection #0 to host rado-rado1stapp.rhcloud.com left intact * Closing connection #0 Hello from rado 1st app on openshift ;)!
Redhat Cloudforms product explained
As the cloud technology continues to evolve we see even more new cool product names that vendors advertise. One of these is Cloudforms from Redhat. But what does Redhat Cloudforms do and where it can be used? The answer can be found in one of the slides from Redhat Summit 2013.
From Introduction to Red Hat Openstack slides we can learn that Cloudforms:
From Introduction to Red Hat Openstack slides we can learn that Cloudforms:
- Is a management platform for heterogeneous clouds.
- It does support RHVE, Openstack, Redhat RDO and proprietary virtualization solutions.
Labels:
cloud,
cloudforms,
openstack,
redhat,
redhat rdo
Bootstrapping a VM in Openstack environment
In this Openstack Architecture, by Russell Bryant presentation from Redhat 2013 summit we can see description of all Openstack components together with best practices how to deploy them to achieve maximum scalability. If you are interested in more details this link will help you to take the next level: Openstack software architecture.
The amount and verbosity of available information can be overwhelming and it may become difficult after reading all of it to answer a single question:
How does a single VM is created in Openstack and how does the Openstack systems interact together to achieve it.
The slide below shows the six steps and hides the necessary complexity (at least at the beginning, for another view take a look at Event flow when a cloud instance is provisioned in Openstack).
The amount and verbosity of available information can be overwhelming and it may become difficult after reading all of it to answer a single question:
How does a single VM is created in Openstack and how does the Openstack systems interact together to achieve it.
The slide below shows the six steps and hides the necessary complexity (at least at the beginning, for another view take a look at Event flow when a cloud instance is provisioned in Openstack).
Labels:
architecture,
booting,
openstack
Sunday, December 29, 2013
Status and maturity of the Neutron in Openstack Havana release
Randy Bias from Cloudscaling organized a meetup and brought together 4 engineers who work on cloud network and Openstack Neutron:
http://www.meetup.com/openstack/events/152128692/
http://cloudscaling.com/blog/cloud-computing/neutron-in-production-work-in-progress-or-ready-for-prime-time/
http://www.slideshare.net/randybias/sfbay-openstack-meetup-neutron-and-sdn-in-production-20131203
Below are some of my notes I took when watching the video.
Key SDN components
Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.
The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.
Neutron
This question was asked at about 41.50. There were different answers.
There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.
- Juniper, Rudra Rugee
- Midokura, Ryu Ishimoto
- VMware, Aaron Rosen
- PLUMgrid, Edgar Magana
http://www.meetup.com/openstack/events/152128692/
http://cloudscaling.com/blog/cloud-computing/neutron-in-production-work-in-progress-or-ready-for-prime-time/
http://www.slideshare.net/randybias/sfbay-openstack-meetup-neutron-and-sdn-in-production-20131203
Below are some of my notes I took when watching the video.
- Network programmability (API)
- Network vitalization (responsible for creating overlay network, multi-tenancy, managing flows, gateways, virtual routers ...)
Neutron is an abstraction layer. It separates your physical network from the direct "tenant network"/virtual network topology. It allows you pragmatically (through a reach API and cli) create virtual routers, lb, firewall. That way it allows you to emulate/virtualize physical devices in cloud.
The main idea is to keep the physical layer as simple and minimal as possible but reach enough so you can create more complex configuration on top of it. That way you can think about Neutron in term of configuration management, orchestration or network vitalization management.
Neutron
- It defines a clear public API how to interact with Openstack to create network objects.
- Provide Network as a Service (NaaS) to tenants to enable more advance deployments and configuration options.
- Initially the goal was to remove the Nova Network from Openstack and create its won project to allow more flexibility and expand functionality (Nova network does support only a limited number of topologies: flat, flat DHCP and VLANs).
- Platform for new future network development in Openstack.
- Neutron is promising a scalable and highly available infrastructure for tenants.
- There are some single point of failures (SPOF) in the current vanilla Havana release. This is one of the differences between the open source vanilla Neutron and vendor specific plugins.
- It provides a choice of technology and no vendor lock-in for network in Openstack. One way of looking at it is that the customer have a choice of what technology/vendor he would like to use to build up the network infrastructure. The there benefit is access to an public open API that is independent of the actual backed technology. But it is important to understand that various backed drivers may provide different and more reach functionality than the Openstack one. In this case you can always get access to this through API extension that Neutron exposes as well. In this sense you can gain additional way of interacting and using your new technology and still remain open and interoperable with feature versions.
- It allows for vendor specific extension for more advance networking features that may not be present in current Neutron API.
- It is the platform to integrate all network functionality in cloud. Although its main focus is on the most common cases and what users demand.
- Openstack wants to be the the reference model for the next generation cloud data center and Neutron aims to provide support for the networking part. By providing a common and widely acceptable platform it opens and allows multi network vendors integration.
- Every vendor can have its own differentiate factors. In the current state of networking industry it is impossible to have a single API in Openstack to address every use case needs. It looks like there will be always space for vendor extension in Neutron for these infrastructure providers or customer who demand more specific and unique features that are not present yet.
- Exposes network abstraction to developers, operation and devops teams who don't need to worry about the implemented details.
This question was asked at about 41.50. There were different answers.
- If you want to run the vanilla Neutron configuration it is not recommend to run it in production without good knowledge of how all Openstack components work and interact together.
- You can run Neutron with vendor plugin in production. By choosing a vendor plugin instead of the vanilla open source solution you get additional level of confidence and support.
- Maybe for private cloud depending on feature requirements and scalability but no for public cloud and enterprise network deployments.
- What level of (technical) support is required before and after implementation.
- How much expertise do you have in your company.
- What scalability do we talk about.
- What application do you want to run.
- What features do you require.
There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.
Labels:
cloud network,
neutron,
openstack
Tuesday, December 17, 2013
How to estimate hardware requirements for your private Openstack deployment
I've found this little tool on the Mirantis web page: http://www.mirantis.com/openstack-services/bom-calculator/. You can play with it to estimate how much hardware (and money as well :)) you need to build your own private Openstack cloud infrastructure. It gives as well as an overview about potential vendors and theirs hardware.
Simple example
Simple example
Labels:
deployment,
hardware,
mirantis,
openstack
Top 10 data center network vendor list
In previous post was saw how handful the Gartner magic quadrants can be when learning and researching particular technology or industry trend:
By the way I was investigating this because of the networks vendor selection on this cloud hardware deployment calculator (How to estimate hardware requirements for your private Openstack deployment ) : Dell, Cisco, HP, Arista, Juniper, Brocade.
- New 2012 Gartner Magic Quadrant for Cloud Infrastructure as a Service (Iaas)
- Rackspace and Brocade pushing ADX platform
By the way I was investigating this because of the networks vendor selection on this cloud hardware deployment calculator (How to estimate hardware requirements for your private Openstack deployment ) : Dell, Cisco, HP, Arista, Juniper, Brocade.
Labels:
cloud network,
deployment,
gartner,
hardware,
magic quadrant,
mirantis,
network,
openstack,
vendor
Monday, December 9, 2013
How to automatically deploy your public ssh key to Openstack cloud server
Keeping secure all your passwords when creating new cloud servers is very unpractical and it is a big management burden.
Problem
How to create a new cloud server and automatically deploy ssh authorized_keys file with our public ssh key.
Solution description with demonstration
References
http://developer.rackspace.com/blog/step-by-step-walkthrough-to-using-chef-to-bootstrap-windows-nodes-on-the-rackspace-cloud.html
Problem
How to create a new cloud server and automatically deploy ssh authorized_keys file with our public ssh key.
Solution description with demonstration
- Generate a new pub and private key pair that your are going to be using with key authentication for all new cloud servers
- Rename and save your keys so you don't override them (keep the private key secure of course!)
- Create a new cloud server (cs) with your public key saved automatically in authorized_keys file
- Login to cs using your private key
References
http://developer.rackspace.com/blog/step-by-step-walkthrough-to-using-chef-to-bootstrap-windows-nodes-on-the-rackspace-cloud.html
Labels:
automation,
cloud server,
openstack
Sunday, November 10, 2013
Openstack Havana Neutron features
There is a new Openstack Havana release available and like with every new release there are new networking features as well. A nice presentation getting straight into the Neutron can be found below.
Openstack Havana Neutron features
References
https://wiki.openstack.org/wiki/ReleaseNotes/Havana
http://www.projectfloodlight.org/indigo-virtual-switch/
http://docs.projectfloodlight.org/display/indigodocs/Frequently+Asked+Questions+%28FAQ%29
Openstack Havana Neutron features
- Firewall as a Service
- Improved L3 router service
- New modular L2 (ML2) plugin
- Indigo Virtual Switch (IVS) - next to OVS new virtual switch implementation for the hypervisor
References
https://wiki.openstack.org/wiki/ReleaseNotes/Havana
http://www.projectfloodlight.org/indigo-virtual-switch/
http://docs.projectfloodlight.org/display/indigodocs/Frequently+Asked+Questions+%28FAQ%29
Labels:
indigo virtual switch,
neutron,
openflow,
openstack,
openvswitch
Thursday, August 29, 2013
VMware NSX network virtualization platform
VMware announced its new product NSX. In comparison it should be the same for network virtualization what flagship iESX product was for host virtualization.
This 2 links give a glimpse into the architecture design:
http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx-network-operations.html
http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx.html
These 2 pictures from the links above give a high level overview what it does and how it should work:
On the VMware page we can find as well as these two videos below that present the virtual network challenge for cloud deployments and shows how to solve it with the help of VMware NSX platform.
http://bcove.me/idrpiovw
http://bcove.me/qe36t4fc
This 2 links give a glimpse into the architecture design:
http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx-network-operations.html
http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx.html
These 2 pictures from the links above give a high level overview what it does and how it should work:
On the VMware page we can find as well as these two videos below that present the virtual network challenge for cloud deployments and shows how to solve it with the help of VMware NSX platform.
http://bcove.me/idrpiovw
http://bcove.me/qe36t4fc
Labels:
cisco,
cloud,
network virtualization,
nexus,
openstack,
vmware,
vmware nsx
Sunday, August 18, 2013
How to create a PTR DNS record on Rackspace Cloud
There is an easy way to create a PTR record on MyCloud portal. But with constant code upgrades and new changes on the portal the button sometimes don't work.
Problem
How to create a reverse DNS (PTR) record for a Rackspace cloud server using API.
Solution
This little script create a PTR records using Openstack Cloud API: dns-ptr-record.py.
Example
Example snippets from ipython console:
References
Problem
How to create a reverse DNS (PTR) record for a Rackspace cloud server using API.
Solution
This little script create a PTR records using Openstack Cloud API: dns-ptr-record.py.
Example
Example snippets from ipython console:
In [57]: rec = {'data': '162.13.2.xyz', 'name': 'yourservername.mydomain.com', 'type': 'PTR'}
In [62]: dns.add_ptr_records(a0,rec)
Out[62]:
[{u'created': u'2013-08-18T18:15:33.000+0000',
u'data': u'162.13.2.xyz',
u'id': u'PTR-579695',
u'name': u'yourservername.mydomain.com',
u'ttl': 3600,
u'type': u'PTR',
u'updated': u'2013-08-18T18:15:33.000+0000'}]
In [67]: dns.list_ptr_records(a0)
Out[67]: [<CloudDNSPTRRecord id=PTR-579695, data=162.13.2.xyz, name=yourservername.mydomain.com, ttl=3600>]
root@manage2:~# dig -x 162.13.2.xyz @dns1.stabletransit.com ; <<>> DiG 9.8.1-P1 <<>> -x 162.13.2.xyz @dns1.stabletransit.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12333 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;xyz.2.13.162.in-addr.arpa. IN PTR ;; ANSWER SECTION: xyz.2.13.162.in-addr.arpa. 3600 IN PTR yourservername.mydomain.com. ;; AUTHORITY SECTION: 2.13.162.in-addr.arpa. 300 IN NS ns.rackspace.com. 2.13.162.in-addr.arpa. 300 IN NS ns2.rackspace.com. ;; Query time: 109 msec ;; SERVER: 69.20.95.4#53(69.20.95.4) ;; WHEN: Sun Aug 18 18:18:49 2013 ;; MSG SIZE rcvd: 130
References
- https://github.com/rackspace/pyrax/issues/79
- http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/ReverseDNS-123457003.html
- http://www.rackspace.com/knowledge_center/article/rackspace-cloud-essentials-6-creating-a-reverse-dns-record
- http://www.rackspace.com/knowledge_center/comment/155017
Thursday, August 15, 2013
Rackspace Openstack lesson learned from continues integration and continuous deployment
When a software like Openstack gets bigger and bigger and some of the old features matures and new are added over time, there are going to be a number of challenges and complexities that you will see.
These challenges will be for the engineering team who wants to keep the development pace and rolling out new features, for the operational team that needs to look after the existing deployed infrastructure and be capable of planning and executing upgraded when needed, as well as for the support team who could be the first front of people who are notified when things get broken and things get broken when you move fast.
As Rackspace is one of the biggest Openstack consumer out there there are couple of lesson we can learn from them.
Continuous Delivery: While developing our OpenStack-based cloud, we created a Continuous Delivery/Continuous Integration model through which every change to the code goes through automated tests. This Continuous Delivery pipeline lets us make a lot of changes quickly and gives us the ability to rapidly and confidently deploy new features.[2]
References
These challenges will be for the engineering team who wants to keep the development pace and rolling out new features, for the operational team that needs to look after the existing deployed infrastructure and be capable of planning and executing upgraded when needed, as well as for the support team who could be the first front of people who are notified when things get broken and things get broken when you move fast.
As Rackspace is one of the biggest Openstack consumer out there there are couple of lesson we can learn from them.
- Continues delivery is an obligatory task if you want to make sure your infrastructure is running the latest code
We’re still plugging away on efforts to do continuous delivery from Nova trunk to our production environments. Our deploy pace has slowed as we are learning how to scale this effort and keep up with the pace of commits. [1]
- You need to have as much automatic testing as possible
To help facilitate progress, we’ve open-sourced our testing framework, Cloud Cafe, and engaged with the community to talk about how we might move our extensive test suite further upstream in the process.[1]
Continuous Delivery: While developing our OpenStack-based cloud, we created a Continuous Delivery/Continuous Integration model through which every change to the code goes through automated tests. This Continuous Delivery pipeline lets us make a lot of changes quickly and gives us the ability to rapidly and confidently deploy new features.[2]
- Your deployment model can take the benefit of the cloud agility
We’re eating our own dog food. We actually use OpenStack to run the control systems for our public cloud.
If we need more API nodes or additional scheduling capacity, we spin up more instances in our infrastructure cloud, which we call iNova. When upgrading nodes, we spin up new instances with the updated software and roll those into the load balancer. If things work as expected, the old instances are deleted. If there are issues, rollback is as simple as putting the old instances back in rotation. This blue/green deployment approach is a well known pattern. But, doing it in the cloud means we don’t have to have two sets of physical hardware standing around for the task. iNova is now being adopted across our cloud engineering teams for development, testing and production uses.[2]
References
- http://www.rackspace.com/blog/ramping-up-our-openstack-investment-involvement/
- http://www.rackspace.com/blog/how-rackspace-re-wrote-the-cloud-with-openstack-continuous-delivery/
- https://github.com/stackforge/cloudcafe
- http://www.slideshare.net/openstackindia/introduction-to-tempest
- https://github.com/openstack/tempest/tree/master/tempest
Subscribe to:
Posts (Atom)



























