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.

SSL certificate chain order matters

The certs we trust are usually stored in the CApath on Linux systems. The file is a simple text file with all the certs concatenated one after another.

Problem  

Does the order of certificated stored in the CAfile chain file matter for the client or server?

Analysis and verification  

The simple answer is it depends. As the certs from the CApath/CAfile are used by the client it is independent of the SSL/TLS server we are connecting to. The implementation details of the servers should matter.

That means that the certificate order is important only to the local client itself. In the SSL handshaking the content of this file is never sent to the server. An example handshaking can be found: here: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html.

To verify of the order of the certs matters for the openssl client we can run the following test. Both files ca1 and ca2 have the same certs but in different order. Example output.

$ openssl s_client -connect 1.1.1.1:443 -state -msg -CAfile ca1
CONNECTED(00000003)
SSL_connect:before/connect initialization
>>> SSL 2.0 [length 0077], CLIENT-HELLO
    01 03 01 00 4e 00 00 00 20 00 00 39 00 00 38 00
    ...
    ab 3b be 51 9d fa 43
SSL_connect:SSLv2/v3 write client hello A
<<< TLS 1.0 Handshake [length 002a], ServerHello
    02 00 00 26 03 01 2b ae 63 1e ec a0 82 a4 dc 25
    a9 4b 71 14 0a 54 2a ce 3d 6f 38 f5 26 e4 dd 8b
    7e e7 94 d5 02 b7 00 00 04 00
SSL_connect:SSLv3 read server hello A
<<< TLS 1.0 Handshake [length 0e16], Certificate
    11 11 0e 12 00 0e 0f 00 05 69 30 82 05 65 30 82
    22 22 a0 03 02 01 02 02 07 2b 86 02 70 e7 be 22
    ...
    09 0c 4d f6 a7 6b b4 99 84 65 ca 7a 88 e2 e2 44
    be 5c f7 ea 1c f5
depth=2 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 /OU=Domain Control Validated/CN=mydomain.mysite.com
verify return:1
SSL_connect:SSLv3 read server certificate A
<<< TLS 1.0 Handshake [length 0004], ServerHelloDone
    0e 00 00 00
SSL_connect:SSLv3 read server done A
>>> TLS 1.0 Handshake [length 0106], ClientKeyExchange
    11 10 21 32 11 10 13 11 13 11 10 7b 1c c1 d1 10
    ...
    81 1f 71 f1 10 12
SSL_connect:SSLv3 write client key exchange A
>>> TLS 1.0 ChangeCipherSpec [length 0001]
    01
SSL_connect:SSLv3 write change cipher spec A
>>> TLS 1.0 Handshake [length 0010], Finished
    11 11 11 1c 1f 13 6f 1d 11 12 1a 19 ed 64 e8 4b
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
<<< TLS 1.0 ChangeCipherSpec [length 0001]
    01
<<< TLS 1.0 Handshake [length 0010], Finished
    14 00 11 1c ed 9d fd 1f ab db ee ef 29 9a 1c 32
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=mydomain.mysite.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
---
Server certificate
-----BEGIN CERTIFICATE-----
AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBCCCCCCCCCCCCCCDDDDDDDDEEEEEEFFFFF
...
111111111111111111111111111111111111111111111111111ah6I=
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=mydomain.mysite.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
---
SSL handshake has read 3710 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID:
    Session-ID-ctx:
    Master-Key: 11861BE5828519468B6C59B0F01D3FF3126EA2B59DFB985E1C7D88B68E63BF399BCDEF7451D68421C2CE344765CDE572
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1392721077
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

References

http://blog.edgecloud.com/post/19519955133/ssl-certificate-chain-order-matters
http://stackoverflow.com/questions/8431528/nginx-ssl-certificate-authentication-signed-by-intermediate-ca-chain
http://rtomaszewski.blogspot.co.uk/search/label/openssl
http://jw35.blogspot.co.uk/2010/05/doing-certificate-verification-in.html

Howto deploy cowsay to all your cloud servers using ansible configuration management

There are many devops tools that you can use. An example tool chain list can be found http://www.rackspace.com/devops/ and if you are more interested in devops in general make a habit to regularly checking our blog at http://developer.rackspace.com/blog.

Demonstration

In this post we are going to create number of fresh cloud servers: mybastion and 7 serverX
We will install ansible on the mybastion.
Once ansible is installed we will configure our remaining serversX.

Howto and results description

• Spin up cloud servers

We are going to use our helper program http://rtomaszewski.blogspot.co.uk/2013/12/how-to-automatically-deploy-your-public.html to spin up the cloud servers first.

 
auxnova --image 80fbcb55-b206-41f9-9bc2-2dd7aac6c061 --flavor 2 mybastion &> mybastion.log
for i in $(seq 1 7); do echo $i; auxnova --image 80fbcb55-b206-41f9-9bc2-2dd7aac6c061 --flavor 2 server$i &> server${i}.log; done

• Install ansible on mybastion host

auxssh bastion-ip  
auxnova --image 80fbcb55-b206-41f9-9bc2-2dd7aac6c061 --flavor 2 mybastion &> mybastion.log
for i in $(seq 1 7); do echo $i; auxnova --image 80fbcb55-b206-41f9-9bc2-2dd7aac6c061 --flavor 2 server$i &> server${i}.log; done

aptitude update
aptitude upgrade

aptitude install libc6-dev  

aptitude install python-dev
aptitude install python-pip

# http://docs.ansible.com/intro_installation.html
git clone git://github.com/ansible/ansible.git
pip install paramiko PyYAML jinja2 httplib2

cd ansible 
make 
make install

export PATH=$PATH:/usr/local/bin/

• Configure ansible on mybastion

cp -vb /root/ansible/examples/ansible.cfg ~/
sed 's/#host_key_checking = False/host_key_checking = False/g' ansible.cfg > ansible.cfg.old && mv ansible.cfg.old ansible.cfg
sed 's/\(transport *= \)\(.*\)/\1 paramiko/' ansible.cfg  > ansible.cfg.new && mv -v ansible.cfg{.new,}

root@mybastion:~# egrep 'host_key_checking|transport' ansible.cfg | column -t
transport          =  paramiko
host_key_checking  =  False

• Update the host file for static DNS names

for i in $(seq 1 7); do nova show server$i | egrep 'accessIPv4| name' | cut -d '|' -f3 | xargs -n2 | awk '{ print $2, $1}'; done
162.13.9.170 server1
162.13.9.102 server2
162.13.11.232 server3
162.13.9.215 server4
162.13.9.59 server5
162.13.11.227 server6
162.13.11.222 server7

cat >> /etc/hosts <<END
162.13.9.170 server1
162.13.9.102 server2
162.13.11.232 server3
162.13.9.215 server4
162.13.9.59 server5
162.13.11.227 server6
162.13.11.222 server7
END

• Configure ansible inventory file

cp -b ansible_hosts{,.old}
rm ansible_hosts
for i in $(seq 1 7); do 
  cat server${i}.log | egrep ' name|adminPass' | cut -d '|' -f 3 | xargs -n2 | sed 's/\([^ ]*\) *\(.*\)/\1 ansible_ssh_user=root ansible_ssh_pass=\2/' >> ansible_hosts;
done

root@mybastion:~# cat  ansible_hosts
server1 ansible_ssh_user=root ansible_ssh_pass=JaD2KJYswZ92
server2 ansible_ssh_user=root ansible_ssh_pass=keic343S3uJt
server3 ansible_ssh_user=root ansible_ssh_pass=2SNvD4cLN36m
server4 ansible_ssh_user=root ansible_ssh_pass=T7VKkm3GLjKm
server5 ansible_ssh_user=root ansible_ssh_pass=ghdWJeKRRt2f
server6 ansible_ssh_user=root ansible_ssh_pass=N2qVsxt93Lfb
server7 ansible_ssh_user=root ansible_ssh_pass=yMgS5Jx4zexM

• Run a test to verify ansible and inventory is setup correctly

root@mybastion:~# ansible all -m ping -i ansible_hosts
server1 | success >> {
    "changed": false,
    "ping": "pong"
}

server3 | success >> {
    "changed": false,
    "ping": "pong"
}

server4 | success >> {
    "changed": false,
    "ping": "pong"
}

server2 | success >> {
    "changed": false,
    "ping": "pong"
}

server5 | success >> {
    "changed": false,
    "ping": "pong"
}

server7 | success >> {
    "changed": false,
    "ping": "pong"
}

server6 | success >> {
    "changed": false,
    "ping": "pong"
}

• Run a simple command

ansible all -i ansible_hosts -a date
ansible all -i ansible_hosts -m command -a /bin/date

server1 | success | rc=0 >>
Mon Feb 10 01:43:49 UTC 2014

server3 | success | rc=0 >>
Mon Feb 10 01:43:49 UTC 2014

server2 | success | rc=0 >>
Mon Feb 10 01:43:49 UTC 2014

server4 | success | rc=0 >>
Mon Feb 10 01:43:49 UTC 2014

server5 | success | rc=0 >>
Mon Feb 10 01:43:49 UTC 2014

server7 | success | rc=0 >>
Mon Feb 10 01:43:50 UTC 2014

server6 | success | rc=0 >>
Mon Feb 10 01:43:50 UTC 2014

• Use ansible modules to install the packages on the serverX

ansible all -i ansible_hosts -m apt -a 'name=cowsay state=installed'
server1 | success >> {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (166 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 50438 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

server4 | success >> { 
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (861 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 49847 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

server3 | success >> {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (1075 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 49847 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

server5 | success >> {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (1116 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 49847 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

server2 | success >> {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (108 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 49847 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

server6 | success >> {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (1292 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 49847 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

server7 | success >> {
    "changed": true,
    "stderr": "",
    "stdout": "Reading package lists...\nBuilding dependency tree...\nReading state information...\nSuggested packages:\n  filters\nThe following NEW packages will be installed:\n  cowsay\n0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.\nNeed to get 19.9 kB of archives.\nAfter this operation, 287 kB of additional disk space will be used.\nGet:1 http://mirror.rackspace.com/ubuntu/ precise/universe cowsay all 3.03+dfsg1-3 [19.9 kB]\nFetched 19.9 kB in 0s (1056 kB/s)\nSelecting previously unselected package cowsay.\n(Reading database ... 49847 files and directories currently installed.)\nUnpacking cowsay (from .../cowsay_3.03+dfsg1-3_all.deb) ...\nProcessing triggers for man-db ...\nSetting up cowsay (3.03+dfsg1-3) ...\n"
}

• Run the cow program on all hosts and collect results

ansible all -i ansible_hosts -m shell -a 'executable=/bin/bash cowsay lucky number on $HOSTNAME is  $RANDOM'
server1 | success | rc=0 >>
 _________________________________
< lucky number on server1 is 9420 >
 ---------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

server2 | success | rc=0 >>
 __________________________________
< lucky number on server2 is 12466 >
 ----------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

server4 | success | rc=0 >>
 __________________________________
< lucky number on server4 is 27268 >
 ----------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

server5 | success | rc=0 >>
 __________________________________
< lucky number on server5 is 26818 >
 ----------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

server3 | success | rc=0 >>
 __________________________________
< lucky number on server3 is 17164 >
 ----------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

server6 | success | rc=0 >>
 __________________________________
< lucky number on server6 is 28732 >
 ----------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

server7 | success | rc=0 >>
 _________________________________
< lucky number on server7 is 6655 >
 ---------------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

References

http://www.ansible.com/home
http://docs.ansible.com/intro_getting_started.html
http://docs.ansible.com/intro_adhoc.html
http://docs.ansible.com/list_of_packaging_modules.html

https://github.com/rtomaszewski/dotfiles/blob/master/.bashrc_rado_aux

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

On Cisco ASA firewall how to find the real Interface MAC address

Normally the output from 'sh interface' shows interfaces MAC addresses. This is truth when you have a single ASA.

Problem

How to find a real interface MAC address on HA ASA cluster node.

Resolution

There are no floating IPs in ASA cluster design. Instead there active IP will be moved between the ASA nodes when a failover occurs. For guys who work on different cluster implementation it may be very confusing.

When a firewall is part of an HA active/standby cluster the physical interface MAC address (showed in the output form sh interface) and the IP assigned to it has always a value of the primary unit.

When a failover happens both ASAs swaps IP and MAC during.

For example, if we have assigned an IP 1.1.1.1 to the primary unit on our ASA cluster this IP will be once held by the unit A once by the unit B. That means, when you try to connect to this IP you never know to what physical ASA unit you are actually connecting.

To find out the real MAC of an interface you need to look at the sh version output.

fw-1092388-553262/pri/stby# sh ver | i Gig
 0: Ext: GigabitEthernet0/0  : address is 1111.aaaa.deea, irq 9   ------  real address on the ASA 
 1: Ext: GigabitEthernet0/1  : address is 1111.aaaa.deeb, irq 9
 2: Ext: GigabitEthernet0/2  : address is 1111.aaaa.deec, irq 9
 3: Ext: GigabitEthernet0/3  : address is 1111.aaaa.deed, irq 9
 
fw-1092388-553262/pri/stby# sh int | i MAC|Int
Interface GigabitEthernet0/0 "outside", is up, line protocol is up
        MAC address 2222.fd52.ac28, MTU 1500                     ------ active MAC that migrates every time a failover happens

Best practice

If you want to know to what physical ASA unit you connected take a look at the output from sh version. Never relay on the values in sh int output.

References

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/ef.html#wp1929064
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ha_overview.html

Google Compute Engine Console

In one of our previous posts (Links to Cloud provider web management consoles) we took a look at some of the major cloud providers out there. In this post we take a look how Cloud Google Compute platform looks like.

• Google Cloud Platform

https://cloud.google.com/