Search This Blog

Showing posts with label architecture. Show all posts
Showing posts with label architecture. Show all posts

Sunday, April 27, 2014

Overlay technologies in data center

Everyone speaks about SDN an the benefits its brings when deploying cloud or enterprise infrastructures. But do we actually know or have any understanding what this all SDN is about? If you want be fluent in the language of virtual networking and network overlays in modern data centers you need to understand at least the following concepts:
In the remaining of the post we will concentrate solely on existing overlay technologies. These information was extracted from Cisco doc: Cisco Nexus 9000 Series Switches - Data Center Overlay Technologies).

Network-Based Overlay Networks
  1. IEEE 802.1ad Provider Bridging or IEEE 802.1q Tunneling also known as IEEE 802.1QinQ or simply Q-in-Q
  2. IEEE 802.1ah Provider Backbone Bridges (PBB) or Mac-in-Mac Tunnels
  3. Cisco FabricPath allows multipath networking at Layer 2
  4. TRILL - IETF Transparent Interconnection of Lots of Links is a Layer 2 multipathing technology
  5. Shortest-Path Bridging (SPB) is defined in IEEE 802.1aq and is targeted as a replacement for Spanning Tree Protocol (example info based on Avaya documentation)
  6. Cisco Overlay Transport Virtualization (OTV) is a Layer 2-over-Layer 3 encapsulation "MAC-in-IP" technology
  7. The Cisco Location/Identifier Separation Protocol (LISP) is currently defined as a Layer 3 overlay scheme over a Layer 3 network
  8. Multiprotocol Label Switching (MPLS)
  9. Virtual Private LAN Service (VPLS) a Layer 2 tunneling protocols
  10. Virtual Private Routed Network (VPRN) also known as BGP/MPLS or IP-VPN provides IP VPN services
Host-Based Overlay Networks
    1. Virtual Extensible LAN (VXLAN) is a Layer 2 overlay scheme over a Layer 3 networ that uses IP/UDP encapsulation
    2. Network Virtualization Using Generic Routing Encapsulation (NVGRE) allows creation of virtual Layer 2 topologies on top of a physical Layer 3 network
    3. Stateless transport tunneling (STT) is an overlay encapsulation scheme over Layer 3 networks that use a TCP-like header

    Saturday, March 8, 2014

    How to build a high performance network appliance like routers using commodity hardware and off the shelf components

    You can assemble a server from off the shelf components that will be able to sent and receive traffic in multi Gigabit speed. Here is an example of an 10Gps net card from Intel.

    But can we turn this server into a high performance network appliance? Do we still need a dedicated hardware like for example ASIC, FPGA, low latency RAM and TCAM RAM in network devise so they can efficiently switch and forward packets with maximum wire speed.

    Router hardware design plan

    Looking at this presentation from 2012 https://ripe64.ripe.net/presentations/18-ripe-64-router-architecture-challenges.pdf you would think that yes. These would be the obvious reasons (screenshots taken from the presentation):





    Network processing unit (NPU) and new hardware design

    The key points listed above still hold. But the next generation network appliances will be rather build with a help of a multicore generic NPU using the power of parallel processing than expensive and purposely design ASIC. With the right software (OS - often Linux, drivers, firmware, SDK, and API libraries) you will be able to turn a conventional x86 server with a modern PCIe data bus into a high performance, low latency and high speed network appliance.

    Netronome Network Cards Accelerate SDN and NFV Designs
    100Gps FlowNIC-6xxx network card
    Hardware reference designs for FlowProcessor NPU chips



    Sunday, February 23, 2014

    How to design a network for Openstack or cloud deployment

    Designing a network is a topic within itself and there is no way we can cover all of it in this single post. Cisco has its own certification path path CCDE for these who want to know more.

    Cisco design and implementation guide - old best practices

    In a very simplistic view back in the old days a network used to be design similar to the picture below (although it is hard to say when the new era started ;)). Every big network had to have a core, distribution(sometimes called aggregation) and access layer. The network was engineered mainly to help with North to South traffic in the data center or in another words to help get the data out and into the data center.


    New cloud friendly data center design best practice

    With the advent and popularization of new networking devises that support layer 2 routing, commonly know as networks fabrics (more info about TRILL and fabric) the network design has shifted in data centers. The way we design the networks today is to maximize the East to West traffic instead of the North to South ( old design above). The purpose of the new network is to allow more efficiently exchange data between the servers within the rack or data center.

    They say that a picture is worth more than a thousand words. To help us to visualize how a new data center network/cloud network is designed these demonstration pictures (taken from Cisco document: Cisco Massively Salable Data Center) will shed some more light on it. Please note that we no longer use the core, distribution or access keyword but instead: spine, leaf or superspine to describe the different network layers :).

    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.


    Wednesday, January 1, 2014

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

    Monday, November 18, 2013

    Network operating system architecture

    In my previous posts we took a look at how hardware networking vendors design and build modern systems. We concentrated mainly on the OS and software integration on the appliance:
    Today I found another good article on Arista blog that takes this one step further and again advocates an open operating system design: Linux as a Switch Operating System: Five Lessons Learned. This is what Arista says:
    • It’s okay to leave the door unlocked - get net admin access to the underlying Linux operating system tools
    • Preserve the integrity of the Linux core - keep your product specific changes as small as possible to allow integration with already existing software out there
    • Focus on state, not messages - being only maybe an average programmer I will not comment on this as this is clearly not my area of expertise
    • Keep your hands out of the kernel - why to complicate your code if it doesn't bring any revolutionary benefit; besides it is much easier to find developers who know how to program in linux/libc than in Linux kernel.
    • Provide familiar interfaces to ease adoption - everyone knows the IOS CLI so why to invent something new.
    Lesson learned from Arista: reuse, integrate and trust your customers.

    The company success would not be possible without a clear and consistent OS and tools set design. From my experience they are the second company (I saw this first on BigIP - F5 load balancers).

    Thursday, June 6, 2013

    Network appliance architecture

    Networking is a fascinating topic. There are thousands of books and RFC describing protocols from layer 1 to layer 7. In every big network we find variety of network devices that handle traffic and provide additional enhanced services. Example of such devices can be switches, routers, load balancers, traffic accelerators, firewalls, IDS, DDOS mitigation devices and others. Services could be QoS, security and traffic deduplication etc.

    Looking at the network devices someone could ask one interesting questions: how to build a network device; how would you describe an internal device architecture?

    Of course every company has its own patents, secrets, methods etc. how they built, manage and operate network appliances. Below are some information I found when working with them or reading about them.

    What OS is used to manage data centre class network appliances from Dell

    Dell acquired Force10 in 2011 and that way gained access to data center networking technologies like 10 and 40 Gigabit Ethernet switches.

    Like many hardware devices a network appliance needs an (network) operating system (NOS) to control resources and to provide monitoring and management interface. Base on the publicly available information a simplified view of a hardware and software architecture for Force10 network devices can be described as:
    References
    1. http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell_Force10_FTOS_Spec_Sheet.pdf
    2. http://i.dell.com/sites/doccontent/shared-content/data-sheets/en/Documents/Dell_Force10_Product_Quick_Reference_Guide.pdf
    This is more like a bonus material in reference to [1] how to build a network using the latest Z9000 switches from Dell: http://bradhedlund.com/2012/01/25/construct-a-leaf-spine-design-with-40g-or-10g-an-observation-in-scaling-the-fabric/

    Tuesday, May 21, 2013

    Architecture frameworks

    Did you see big systems implementations?
    Did you participated in a system implementation or deployment?
    What is your current role?
    What is your carrier goal?

    Every company is organised in a different way. Every company is build in a different way. But it all starts from a vision that is going to be mapped into an architecture. Once the concept or the first sketches of the architecture are established the implementation process is going to follow.

    It is an example how it can look like. If you are interested in other options it is worth to take a look at some of the established (enterprise) architecture frameworks. Generally speaking, it is rather a quite difficult document to read as it tries to address the issue of an enterprise company. But even though its complexities it still gives a good overview how complex some processes, implementations or deployments can be. Below is a table from FEAF framework that list key roles and teams for an organisation.



    This one below shows the concept of an architecture from a high level point of view.


    The more detailed description of the architecture domains can be found here. Personally, I'm specializing in the area of technical infrastructure architecture. With the specialization in virtual networking and cloud network in IaaS cloud.

    Technical architecture or infrastructure architecture: The structure and behaviour of the technology infrastructure. Covers the client and server nodes of the hardware configuration, the infrastructure applications that run on them, the infrastructure services they offer to applications, the protocols and networks that connect applications and nodes.

    References
    1. http://en.wikipedia.org/wiki/Solution_architecture
    2. http://en.wikipedia.org/wiki/Architecture_domain
    3. http://en.wikipedia.org/wiki/TOGAF
    4. http://pubs.opengroup.org/architecture/togaf8-doc/arch/
    5. http://en.wikipedia.org/wiki/Multitier_architecture
    6. http://en.wikipedia.org/wiki/Peer-to-peer

    Saturday, May 18, 2013

    Arista network operating system switch architecture

    Arista belongs to the vendor elite list designing and building network equipment for the next generation of data centers to support cloud and virtual network workloads. What is cool about this vendor is it unique and open network operating system architecture: Arista EOS.

    System architecture

    It is built on top of a Linux Fedora distribution. From high level point of view it has a similar design architecture like BigIP LTM from F5 Networks (TMOS architecture link1/link2). The pictures below show architecture design for EOS.





    Linux Bash access

    As an engineer, after login you get access to the Linux Bash shell on Arista switch. From there you can run the switch CLI commands or get access to the whole list of Linux standard commands. You can run top to list processes, use ls -la to list files, less to see file content and most importantly run tcpdump to capture traffic. All good Linux staff and not some vendor custom magic tool set.

    Configuration CLI

    The CLI mirrors many of the Cisco commands:

    Example : port mirroring
     
    7050-1(config)#monitor session test1 ?
    destination  Mirroring destination configuration commands
    source       Mirroring source configuration commands
    
    7050-1(config)#monitor session test1 source ?
    Ethernet      Ethernet interface
    Port-Channel  Lag interface
    
    7050-1(config)#monitor session test1 source ethernet 1 ?
    both  Configure mirroring in both transmit and receive directions
    rx    Configure mirroring only in receive direction
    tx    Configure mirroring only in transmit direction
    ,     extend list
    -     specify range
    
    7050-1(config)#monitor session test1 source ethernet 1
    7050-1(config)#
    

    Example : show port-channel
     
    Arista:(config-if-Et1)#show port-channel 20 detail
    Port Channel Port-Channel20:
     Active Ports:
     Port                Time became active       Protocol    Mode 
     ------------------- ------------------------ -------------- ------ 
     Ethernet1           14:53:02                 LACP        Active
    Ethernet2          14:52:57                 LACP        Active 
    

    Example : capturing network data
     
    tcpdump -i et12 -vvv > /tmp/tcpdumpe12.txt
    

    Extensions

    As the system provide Python execution environment you can easily customize it and write your own extension. An example of a Python script for gateway monitoring can be found here: Dead Gateway Detection.

    References
    1. https://eos.aristanetworks.com/wiki/index.php/EOS
    2. https://eos.aristanetworks.com/wiki/index.php/What_is_the_underlying_Linux_OS%3F
    3. https://eos.aristanetworks.com/wiki/index.php/What_is_the_underlying_architecture_of_EOS%3F
    4. https://eos.aristanetworks.com/wiki/index.php/Is_it_truely_a_single_code_version_across_all_platforms%3F
    5. https://eos.aristanetworks.com/wiki/index.php/EOSTips
    6. https://eos.aristanetworks.com/techtips/
    7. https://eos.aristanetworks.com/devblogs/
    8. https://eos.aristanetworks.com/2012/12/introduction-to-port-mirroring/
    9. https://eos.aristanetworks.com/wiki/index.php/4._Watching_interface_statistics_real_time
    10. https://eos.aristanetworks.com/wiki/index.php/6._tcpdump_on_switch_and_redirect_output_via_email/TFTP/FTP

    Friday, May 17, 2013

    Performance analysis of network tunnels in SDN cloud network

    Additional network overlay is the foundation and building block for most modern cloud network architectures today. In practice it means that before we can even think how to architect and build network for the cloud we need to build a solid and reliable multi-tiered IP network topology to interconnect our hypervisors servers. Of course this is a big simplification and there are many vendors that provide hardware support for cloud network (SDN enabled network). Examples are Brocade VCS/MLX or Cisco Nexus platform/Random thoughts about Cisco nexus product line.

    But what is important is that in essence what we are going to built will be a typical multi-tier network with access, distribution and core layers like this example below:


    Once the network is built there is now time for the cloud network element to be added. This is again very simplistic view to avoid all the technical details.

    The industry is still working to established a common ground and consensus how a cloud network should look like and what services it should provide but in practice (base on a few companies like Nicira or Midokura) it is tightly associated with  Software defined networking (SDN) concept and architecture. And the common practice today is to implement SDN network as an additional network overlay on top of IP fabric infrastructure.

    Like every network, cloud network needs to provide IP connectivity for cloud resources (cloud servers for example). Often to achieve this al hypervisors are inter-connected using tunneling protocols. This model allow us to decouple the cloud network from the physical one and allow more flexibility. That way all VMs traffic is going to be routed within the tunnels. To solve the cloud network problem is to find a solution how to route between the hypervisors using the tunnels.

    Data flows, connections and tunnels are manged by cloud controller (a distributed server cluster) that need to be deployed in our existing physical network. An example of Nicira NVP controller can be found here: Network Virtualization: a next generation modular platform for the data center virtual network.

    As we agreed VMs data will be routed within tunnels. These are the most popular ones: NVGRE, STT and VXLAN (Introduction into tunneling protocols when deploying cloud network for your cloud infrastructure).

    As tunnels require additional resources there is an open question what overhead, resource consumption and performance implication will they represent. This post: The Overhead of Software Tunneling (*), do a comparison and tries to shed some more light on the topic.

    ThroughputRecv side cpuSend side cpu
    Linux Bridge:9.3 Gbps85%75%
    OVS Bridge:9.4 Gbps82%70%
    OVS-STT:9.5 Gbps70%70%
    OVS-GRE:2.3 Gbps75%97%

    This next table shows the aggregate throughput of two hypervisors with 4 VMs each.

    ThroughputCPU
    OVS Bridge:18.4 Gbps150%
    OVS-STT:18.5 Gbps120%
    OVS-GRE:2.3 Gbps150%

    We can see that not all tunnels are completely transparent when it comes to performance. The GRE tunnel shows a significant degradation in throughput. The TCP based STT tunnel works fine although  For a complete analysis, explanation and further discussion I recommend to read the blog above (*).

    References
    1. http://rtomaszewski.blogspot.co.uk/2012/12/what-do-you-need-to-implement-virtual.html
    2. http://rtomaszewski.blogspot.co.uk/2012/11/what-network-topologies-can-i-build.html
    3. http://rtomaszewski.blogspot.co.uk/2012/11/after-server-virtualization-there-is.html
    4. http://rtomaszewski.blogspot.co.uk/2013/05/sdn-system-software-architecture.html
    5. http://bradhedlund.com/2012/10/06/mind-blowing-l2-l4-network-virtualization-by-midokura-midonet/
    6. http://blog.ioshints.info/2012/08/midokuras-midonet-layer-2-4-virtual.html

    Wednesday, May 8, 2013

    SDN system software architecture

    By reading about various companies like (Nicira, Midokura) that provide SDN solutions you hear various technology acronyms like Openflow, Openvswitch and others. After a while once you allow this knowledge to sink your appetite grows and you begin to ask more questions like:
    • How did they create this
    • What tread off and compromises exist in the architecture
    • What could be the limitations
    • How complex is the architecture and deployment
    • What software, languages etc.. did they use
    • How much operational intensive it is to support this 
    It is hard and even impossible to answer all of them fully but I hope the little info below will help to fill some of the gaps.
    Vendor advertised information 

    There is no much info about internal architecture or deployment options on the vendor's home site. We can find only very generic descriptions like the ones below.

    Nicira [1]

    What is Nicira's architecture?
    Nicira's Distributed Virtual Network Infrastructure (DVNI) is an architecture that builds on a distributed software system that decouples virtual services from the network hardware and works with any server hypervisor. 

    How does the platform work?
    The NVP Controller Cluster dynamically updates the state of tunnel connections between OVS switches through the physical network. These tunnels allow virtual networks to span across the data center, even between data centers. Data communications between workloads connected to virtual networks is encapsulated and traverses the physical network, enabling VM mobility across subnet boundaries, while maintaining L2 adjacency. The operational state of the network is computed algorithmically in the NVP Controller Cluster,

    Midokura [2]

    Fully Distributed Architecture with no single points of failure

    Midokura has built MidoNet to be completely distributed and scalable. These advantages are key in building your infrastructure.

    Furthermore, MidoNet is a completely distributed scale-out system, offering no single point of failure.


    Architecture differences

    But there is one thing that can be read between the lines. Although both vendors claim to offer SDN solution that is based on a distributed architecture is seems they interpret this in a different way.

    It looks like that for Nicira the distributed attribute is mainly a property of its NVP cluster. NVP is a central place that holds all network (like flows, port, tenants, network ...) related information that is relevant to implement a control plane.

    For Midokura the distributed attribute is a way they designed the whole solution they have. There is no single central component (in a form of a single or multi-server distributed cluster) that holds and manages all network information. It looks like that every Midonet node has limited knowledge but in the same time has enough information to perform tasks done normally by the control plane.

    Comparison of the architecture types

    Depending on the architecture type both companies facing different challenges that they need to solved. An interesting summary of types and problems that you may encounter can be found in this wiki article SDN deployment models. The article list following types that matching quite well above descriptions that should give us enough info to realize how different are both approaches:
    • Symmetric vs asymmetric
    • Floodless vs flood-based
    • Host-based vs Network-centric
    References
    1. http://nicira.com/en/frequently-asked-questions
    2. http://www.midokura.com/midonet/openstack/
    3. http://www.midokura.com/for-enterprise-and-government/for-service-providers/
      http://www.midokura.com/for-enterprise-and-government/

    Thursday, March 28, 2013

    Quick overview of AppFog PaaS platform

    There is Openstack that aims to provide opensource IaaS solution for the Internet. But cloud has many faces and in a simplistic cloud taxonomy we can speak of IaaS, PaaS and SaaS as the main trends in the industry.

    The video below provide a short introduction and comparison of Openstack and Appfog that is based on CloudFoundry. Both products embracing the open source developed paradigm. Both try to define standard and become leader in the respective domain.


    As a bonus material for these who are interested in the overall technical system architecture this link  provide slides and video of Derek Collison (a lead technical architect for CloudFondry at Vmware) Cloud Foundry: Inside the Machine

    Demonstration and example
    1. You need to create a basic account that is free (but has resource limitation)
    2. You can use the GUI to create your fist application
    3. Use the CLI af (docu here) to get a look and feel what it is 
    This is the automatically generated demo.
     
    $ curl -v http://rado-python.hp.af.cm/
    * About to connect() to rado-python.hp.af.cm port 80 (#0)
    *   Trying 15.185.166.79... connected
    > GET / HTTP/1.1
    > User-Agent: curl/7.22.0 (i686-pc-cygwin) libcurl/7.22.0 OpenSSL/0.9.8r zlib/1.2.5 libidn/1.22 libssh2/1.2.7
    > Host: rado-python.hp.af.cm
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Server: nginx
    < Content-Type: text/plain
    < Keep-Alive: timeout=300
    < Content-Length: 34
    < Accept-Ranges: bytes
    < Date: Thu, 28 Mar 2013 01:25:30 GMT
    < X-Varnish: 816993201
    < Age: 0
    < Via: 1.1 varnish
    < Connection: keep-alive
    <
    * Connection #0 to host rado-python.hp.af.cm left intact
    * Closing connection #0
    Hello World! AppFog Python Support
    

    Some info about the application hosted on AppFog.
     
    C:\Users\radoslaw>af login
    Attempting login to [https://api.appfog.com]
    Email: xxx
    Password: ************
    Successfully logged into [https://api.appfog.com]
    
    C:\Users\radoslaw>af info
    AppFog Free Your Cloud Edition
    For support visit http://support.appfog.com
    
    Target:   https://api.appfog.com (v0.999)
    Client:   v0.3.18.12
    
    User:     xxx
    Usage:    Memory   (384.0M of 2.0G total)
              Services (1 of 8 total)
              Apps     (2 of 9999 total)
    
    # download the source code 
    C:\Users\radoslaw\workspace\appfog>af pull rado-python
    Pulling last pushed source code: OK
    

    The source code for our fist hello word application is very simple.
     
    import bottle
    import os
    
    def application(environ, start_response):
        data = "Hello World! AppFog Python Support"
        start_response("200 OK", [
                ("Content-Type", "text/plain"),
                ("Content-Length", str(len(data)))
                ])
        return iter([data])
    

    By default only one instance (cloud server?) is spin up to host our app.
     
    C:\Users\radoslaw\workspace\appfog>af stats rado-python
    
    +----------+-------------+----------------+--------------+---------------+
    | Instance | CPU (Cores) | Memory (limit) | Disk (limit) | Uptime        |
    +----------+-------------+----------------+--------------+---------------+
    | 0        | 0% (4)      | 26.1M (128M)   | 7.1M (1G)    | 0d:0h:58m:18s |
    +----------+-------------+----------------+--------------+---------------+
    
    C:\Users\radoslaw\workspace\appfog>af instances rado-python
    
    +-------+---------+--------------------+
    | Index | State   | Start Time         |
    +-------+---------+--------------------+
    | 0     | RUNNING | 03/28/2013 12:34AM |
    +-------+---------+--------------------+
    

    On the GUI we can quickly and easily increase the number of instance. Once new instance is spun up and application code is cloned to it we see the changes on the CLI as well.
     
    C:\Users\radoslaw\workspace\appfog>af stats rado-python
    
    +----------+-------------+----------------+--------------+--------------+
    | Instance | CPU (Cores) | Memory (limit) | Disk (limit) | Uptime       |
    +----------+-------------+----------------+--------------+--------------+
    | 0        | 0% (4)      | 26.1M (128M)   | 7.1M (1G)    | 0d:1h:2m:35s |
    | 1        | 0.7% (4)    | 26.0M (128M)   | 0B (1G)      | 0d:0h:0m:58s |
    +----------+-------------+----------------+--------------+--------------+
    
    C:\Users\radoslaw\workspace\appfog>af instances rado-python
    
    +-------+---------+--------------------+
    | Index | State   | Start Time         |
    +-------+---------+--------------------+
    | 0     | RUNNING | 03/28/2013 12:34AM |
    | 1     | RUNNING | 03/28/2013 01:35AM |
    +-------+---------+--------------------+
    

    After the testing we delete our application.
     
    C:\Users\radoslaw\workspace\appfog>af delete rado-python
    

    References
    1. https://docs.appfog.com/getting-started/af-cli#max-os-x-linux
    2. http://blog.appfog.com/getting-started-with-appfogs-command-line/
    3. http://net.tutsplus.com/articles/editorials/appfog-vs-heroku/

    Sunday, December 9, 2012

    High availability pattern using anycast IP addresses for cloud and applications

    Anycast architecture that helps to create and achieve HA

    To run efficiently applications demands more and more resources. Even with the right amount of computational resources like servers, CPU, RAM, storage for them to be considered efficient and successfully on the market they have to meet many more requirements. It is impossible to list here all of them as they can depend on internal factors (for example driven by the application architecture itself ) or relay on external factors that may be specific and unique to a customer and an environment.

    Although in this short blog post, I would like to discuss the importance of scalability factor and show one patters that can be used to build a highly available and efficient infrastructure systems.

    There are two concept how we can try to implement a scalability: scale up vs scale out. For more information about scale up (or vertical scaling) these links provide further information [1]. We will concentrate here only on the scale out option. All the pictures below are base on this presentation that slides can be found here: OpenStack-Design-Summit-HA-Pairs-Are-Not-The-Only-Answer.
    1. To fully benefit from the HA pattern your application architecture should relay use share nothing paradigm

    2. That way if failure occurs only an isolated, small part of the computational resources will be impacted.


    3. Next we have to configure our routers and implementing necessary changes for a routing protocol.
    4. OSPF routing protocols is an examples and others can be used in similar way as well. For more info can be found here [4].


      The slides show only a fraction of the configuration. Another good example with con figs can be found here:  Anycast DNS - Part 4, Using OSPF

    5. As last you have to configure you servers to listen and accept traffic for our anycast IP.
    A best practice is to configure the external IP on the loopback interface, disable ARP protocols for it and bind our application specifically to this IP.

    References
    1. http://en.wikipedia.org/wiki/Scalability
    2. https://devcentral.f5.com/blogs/us/lots-of-little-virtual-web-applications-scale-out-better-than-scaling-up
    3. Seattle Conference on Scalability: Lessons In Building Scalable Systems
    4. What is “anycast” and how is it helpful?

    Thursday, November 15, 2012

    What network topologies can I build with Openstack Quantum server

    The Folsom Openstack release brings many enhancements to networking stack in the Openstack version of the cloud. The features have been encapsulated with in a new core project called Quantum. But even looking at the documentation it can be very difficult at the beginning to understand what are the differences to old nova-network solution and how an example Quantum virtual network can be configured.

    Fortunately there is an easy to follow video introduction to Quantum from last Summit [1]. The slides to it can be found here as well [2].

    Below are example slides from the presentation of how a virtual network can be build and how it can look like in cloud powered by Openstack, examples: single flat network, multiple flat networks, mixed flat plus private networks, single provider network, multiple per tenant private networks plus single provider network.






    References

    1. OpenStack Networking (Quantum) Project Update 
    2. http://www.slideshare.net/danwent/quantum-grizzly-summit 
    3. More slides about Quantum from Dan Wendlandt at slideshare

    Sunday, November 11, 2012

    High level Openstack software architecture

    This is an overwhelming task of tracking code changes for Openstack projects as well as to maintain an up to date view of current software architecture model. As the number of core Openstack projects increase it drives as well as the overall complexity and communication patters between the them.

    Below is a nice diagram that through visualization helps to represent the complexities and simplify the communications view between all components in Folscom Openstack release.




    Sources
    1. http://ken.pepple.info/openstack/2012/09/25/openstack-folsom-architecture/
    2. http://ken.pepple.info/openstack/2012/02/21/revisit-openstack-architecture-diablo/

    Monday, October 15, 2012

    Redhat application deployment automaton with Puppet module and F5

    I have found this youtube video [1] on the the Puppet channel. It is an interesting presentation about the day to day issues the folks from Redhat run into when developing, managing and deploying new code for customer facing sites they host.

    On of the things they mention that was difficult for them and why the started this project were:

    • Lack of a cross functional team who could understand the whole architecture.
    • People tend to have a limited understanding of other areas that they don't work in; Examples are SysAdmin about NetAdmin, NetAdmin about Develpers etc.
    • On new depoyment a difficulties to find a team/person who can take an ownership of an issue as the problem may be above the area of their own expertise.
    • Diverse and inconsistencies dev, staging and production systems.

    To solve the problem they decided to refactor the architecture and automate as much as it was possible. The video [1] shows what issues they run into and how they solved it with a help of Puppet module they created and the F5 load balancer.

    In short a message they convey in the presentation is: automate, standardize, and automate once again.

    References
    1. Managing F5 LTM with Puppet - Matthew Carpenter and Bret McMillan of Red Hat
    2. http://www.youtube.com/user/PuppetLabsInc

    Sunday, August 12, 2012

    High Availability trends and architectures in cloud computing

    Every now and than there is a shift and change in IT industry. The changes try to provide a solution to our old problems and try to as well as predict and introduce new ideas. Many times it is not only a change in hardware itself or a change in software only but a mixture of both.

    The Cloud is today the buzz word that drives the changes and powers the transformation. In my attempts to embrace and understand what it is I have found couple if videos on YouTube that give us a very nice inside view into the cloud what it is, how this works and what ideas it brings with. 

    This is a link to the repository of all videos: http://www.youtube.com/user/TheCloudcastNET

    The one I particularly like because it is discussing concept of High Availability in Cloud: