Search This Blog

Showing posts with label openstack. Show all posts
Showing posts with label openstack. Show all posts

Sunday, February 23, 2014

Openstack reference architecture using Cisco UCS hardware platform

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.


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

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:
  • High position for IBM. 
  • Not Rackspace or Canonical or Mirantis but Red Hat as a number one contributor.
Top 10 Openstack organizations activities in 2013/2014


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/



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
  • Public Cloud
Of course for the cloud to exists the physical sever where the hypervisor runs (Xen or KVM for example) needs to have in-hardware virtualization support (Intel VT-x or AMD-V). This is the only way to provide a high performance cloud servers.

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 
The nested virtualization can be enabled. As an example this link describe some of the steps for Linux KVM:
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.
 
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:

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

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:
  • 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 

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



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
  • 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:
  • Is a management platform for heterogeneous clouds.
  • It does support RHVE, Openstack, Redhat RDO and proprietary virtualization solutions.

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).

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:
  • Juniper, Rudra Rugee
  • Midokura, Ryu Ishimoto
  • VMware, Aaron Rosen
  • PLUMgrid, Edgar Magana
More info about the meetup can be found here:
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
  • Network programmability (API)
  • Network vitalization (responsible for creating overlay network, multi-tenancy, managing flows, gateways, virtual routers ...)
What cloud network is and what Openstack Neutron is trying to solve

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.
Would you run vanilla Openstack Neutron in production

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.
The choice between Neutron Openstack vanilla vs vendor plugin needs to be always analyzed individual per customer.
  • 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.
Other issues

There aren't many good troubleshooting tools.
It is difficult to see and track a specific VM to VM traffic.

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


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:
Below is an another comparison chart, this time targeting vendor network equipment in data centers.


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.

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
  • 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

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
  • 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

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

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:
 
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
  1. https://github.com/rackspace/pyrax/issues/79
  2. http://docs.rackspace.com/cdns/api/v1.0/cdns-devguide/content/ReverseDNS-123457003.html
  3. http://www.rackspace.com/knowledge_center/article/rackspace-cloud-essentials-6-creating-a-reverse-dns-record
  4. 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.
  • 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
  1. http://www.rackspace.com/blog/ramping-up-our-openstack-investment-involvement/
  2. http://www.rackspace.com/blog/how-rackspace-re-wrote-the-cloud-with-openstack-continuous-delivery/
  3. https://github.com/stackforge/cloudcafe
  4. http://www.slideshare.net/openstackindia/introduction-to-tempest
  5. https://github.com/openstack/tempest/tree/master/tempest