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

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

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

Akanda virtual router for virtual networks in Openstack

The Openstack virtual network, aka Neutron (old name Quantum) is responsible to deliver networking services for other cloud infrastructure projects. There is already quite a lot about it on the Internet and we reviewed couple of  possible deployment scenarios and use cases here (Emerging of the virtual network aka Quantum in Openstack) as well. Going further this route and discussing virtual networking opportunities it is a time to ask another question:

Does Openstack Virtual Network/Quantum/Neutron support virtual routers?

I don't have yet a very clear answer to this but found today this interesting project: https://github.com/dreamhost/akanda.

Looking at DreamHost wiki we can see that they use it to solve a problem of distributing and redirecting traffic in multi tenancy environment to secure, extend and control the networking traffic. As they claim it is being implemented with a help of virtual router, aka akanda.

http://wiki.dreamhost.com/DreamCompute_Overview

Network

Networking services for DreamCompute are delivered through OpenStack's Quantum service, coupled with Nicira's NVP (Network Virtualization Platform), and DreamHost's own Akanda project.

Nicira initiated and leads the Networking project team within the OpenStack community. Nicira's NVP, in concert with the OpenStack Quantum project, provides the ability to create private networks per tenant with high availability and network hardware independence. Nicira's NVP virtualizes the network; the software does for networks what hypervisors do for servers.

Another component to DreamCompute networking is the open source Akanda project developed by DreamHost. Akanda serves as a network traffic router (OSI Layer 3) for virtual networks created in DreamCompute. Akanda allows virtual networks to be configured to talk to each other, to LANs, to WANs or to the Internet.

The combination of OpenStack, Nicira and Akanda bring a level of network flexibility and security that sets DreamCompute apart from the competition.

Problem booting virtual F5 LTM on Virtual box

There is no better way to learn about LTM load balancer then playing and testing it even though it may be a virtual appliance and running LTM  10.1 version.

To get started download the LTM BIGIP-10.1.0.3341.1084.ova software and the base registration key (you will need to register first).

Problem

After you import the ova file and boot the BigIp you can be presented with the following error:

 
Memory for crash kernel (0x0 to 0x0) notwithin permissible range

Resolution

The VM should be bootable out of the box on a PC with an Intel CPU  64bit. If you are using AMD 64bit system instead you need to enable the "Enable IO APIC" option under VM properties, System, Motherboard.

After the change the system will still show the message but the booting process will no longer stop.

After the system boots login as root/default. Finds the management ip and using your OS browser navigate to https://ip to activate the trial license.

 
tmsh list /sys management-ip

References

https://www.f5.com/trial/
http://lost-and-found-narihiro.blogspot.co.uk/2011/04/how-to-fly-big-ip-ltm-ve-in-vmware.html
https://forums.virtualbox.org/viewtopic.php?f=5&t=24988