As you may have seen, last week we announced the opening of GoGrid’s European Headquarters in Amsterdam. This is an exciting milestone for GoGrid since it means that GoGrid’s cloud infrastructure is now available in even more locations across the globe and with a European data center, sales and account support. Talk is cheap though, so we wanted to provide new and existing GoGrid customers the opportunity to gain “early access” to our European cloud so that it can be experienced first-hand.

Whether you are new to GoGrid or an existing customer, we can grant you early access to the GoGrid Amsterdam data center easily. Choose one of the options below:

• New GoGrid Users – Please visit the GoGrid signup page: https://securesignup.GoGrid.com and use promocode: AMSGG100. The promocode will grant you access to deploy infrastructure within the new Amsterdam data center as well as provide you with a $100 service credit.
• Existing GoGrid Users – Please contact your GoGrid Account Representative about VIP early access and pricing.

Please note, for new users, the promo code can only be used between January 30^th, 2012 and February 13^th, 2012 and will last through February 29^th, 2012 or when the $100 cap is reached, whichever comes first).

We look forward to your feedback on our new data center and should you want to learn more about European presence and to download our Cloud Computing 101 Toolkit, which is a collection of white papers, industry research, analyst reports, case studies and videos, please visit: http://go.gogrid.com/amsterdam_launch/ .

At GoGrid, we are often asked to provide solutions for a variety of use cases. More often than not, businesses are not looking for “standard” cloud implementations. And what really is “standard?” When you think about it, every business has unique needs in order to satisfy their cloud challenges. We help companies craft these solutions daily and we call it Creating a Cloud Fingerprint. But, as is the nature of cloud computing, many users desire to figure it out themselves, simply because solutions can be architected fairly easily, and if it isn’t quite right, they can be modified.

In our regular discussions with companies looking for information on how they can benefit from cloud Infrastructure as a Service, we often come across the same set of hurdles, namely:

• Most established companies have an existing infrastructure investment, and may not be willing or able to sacrifice these investments,
• Some infrastructure components may not be generally available through IaaS vendors, such as Enterprise security or storage infrastructure,
• Some applications or data will be deemed “too sensitive” for the cloud due to internal objections or compliance constraints,
• Maintaining and growing an on-premise solution or even data center is not only difficult, but extremely expensive,
• Doing a full migration to the cloud comes with a very high conversion and operational cost,
• Business simply are unsure as to how to best leverage cloud computing.

With these challenges in mind, we have a solution that allows business not only to utilize their existing infrastructure, but also leverage GoGrid’s public cloud to create a Virtual Private Cloud on GoGrid.

But, addressing the points above is critical in the solution. Therefore, we wanted to be sure:

• Customers could retain their existing infrastructure,
• GoGrid’s platform is used as an EXTENSION of that infrastructure,
• GoGrid’s customers have a wide range of network security options/policies available,
• Customers are able to fully leverage the advantages of cloud infrastructure, and the elimination of capital expenditures and their associated resource costs,
• A customer can fully utilize their existing infrastructure investment.

The GoGrid Solution

The solution is actually quite straight forward. And it aids customers in potentially moving on-premise infrastructure to the cloud in the future at a gradual pace. As we all know, a picture is worth 1000 words:

Each GoGrid account includes dedicated Layer-2 Public and Private VLANs —  this means that GoGrid completely and securely segregates each customer’s data in motion from every other GoGrid customer’s. It also means that all virtual and physical servers can speak directly to each other over high-throughput, low-latency gigabit networks.

Capitalizing on this built-in security and performance, GoGrid can add a full-featured network firewall, completely controlling network traffic per customers’ specifications.

In the Virtual Private Cloud (VPC) configuration, all traffic is denied to and from the Internet, but all traffic is allowed over the secure, encrypted point-to-point link between the customer’s cloud infrastructure at GoGrid, and their on-premise or hosted infrastructure. Of course, this policy set can be modified to add more or less restrictive policies, for example to allow database or remote management traffic only over the VPN, but allow secure web services (HTTPS) over the Internet or an IP range.

What is depicted above is the linking of two distinct infrastructures, one within GoGrid and one as a customer’s on-premise environment. The linkage is done simply by using a VPN/Firewall solution, which creates and encrypted tunnel between the two locations: GoGrid cloud and customer’s location. This is a dramatically over-simplified representation, so let’s take a look at one possible solution in a bit more detail.

The solution above requires the following items:

Within GoGrid

• A GoGrid Account
• A Managed Hardware Firewall
• Cisco ASA-Series Firewall (Single Tenant)
• Fortinet Firewall (Multi-Tenant)

Within Customer’s On-Premise Infrastructure

• A VPN termination appliance at the customer’s location, such as a Cisco, Juniper or Netscreen device

In order to set up this configuration or other versions of GoGrid’s Virtual Private Cloud solution, we recommend that you have a discussion with a Cloud Specialist or Solutions Architect, as it is important to not only properly configure the environment, but also, you will need to order some managed firewall solutions.

Pricing starts around $200/month for a Virtual Private Cloud implemented with the Fortinet Firewall, and $350/month for a managed Cisco ASA 5510 dedicated to a single customer account. These charges are in addition to associated GoGrid infrastructure and bandwidth costs.

Who Might Benefit from a Virtual Private Cloud?

The nice thing about cloud computing is that it can be a solution for just about any use case. Having flexibility to construct solutions using a variety of cloud services allows customers to truly craft their Cloud Fingerprint. In the case of Virtual Private Clouds, we see them as being beneficial for Internal Applications where security of data is paramount. Core private data is maintained within a customer’s location, however, if transmitted to the cloud, it is done via a securely, encrypted tunnel. Some environments that may require this include:

• Microsoft Exchange
• Microsoft SharePoint
• Billing & Financial Systems

Similarly, Virtual Private Clouds can be used for Intranet solutions as well as SaaS applications. Lastly, having a pre-constructed Virtual Private Cloud allows you the flexibility to Cloud Burst should your internal environment suddenly need to leverage more capacity or compute power from GoGrid’s public cloud.

And, as your company’s business and infrastructure grows, you may want to consider a migration to GoGrid’s Hosted Private Cloud which offers the benefits, capabilities and flexibilities of GoGrid’s public cloud, but within a single-tenant environment, one that is dedicated to your company solely.

Regardless, the important point here is to carefully plan for your future infrastructure growth. Don’t do it alone either. Ask your peers as well as your cloud partner to provide you with best practice solutions to make you successful and timely in your efforts.

Zeus is a new GoGrid partner that provides a software load balancing product as a partner image called “Zeus Load Balancer 200Mbps”. There are three immediate features that come to mind when thinking about how to leverage Zeus within GoGrid: Load Balancing, Failover and Clustering. Note that this first image is a preview with certain feature set. It contains the majority of Zeus features but is capped at two clustered servers and 200 Mbits of bandwidth. Additional images are expected to be released by the end of the year.

This tutorial assumes that you have basic understanding of Linux and SSH as well as basic load balancing and failover strategies.

Cross Data Center Load Balancing / Failover

One of the main uses cases for Zeus is to load balance servers in the same data center. However, a more interesting use case is to quickly and easily load balance web servers within one data center and support failover to another data center. The process is straight forward. First, deploy the Zeus partner image as a VM with 1G RAM in the US-West-1. This example assumes that you already have web servers running on both the US-West-1 and US-East-1 data centers.

Once the Zeus image has been deployed, SSH into the server using the root login. Your logins can be found in the GoGrid web portal by clicking on the server icon, then Tools > Passwords.

We recommend changing your automatically created, default password as soon as you login.

The Message of the Day (MOTD) will have links to additional information and support. To begin, run the configuration (/usr/local/zeus/zxtm/configure). Note that you will be prompted to enter the license key. The key is located at /root/license.txt.

Once the configuration is complete, launch the web interface, typically https://IP_ADDRESS:9090

When you first launch the Zeus admin portal, you will be presented with a warning from your browser. This is because the Load Balancer requires a secure connection and is using a self-signed certificate. Most likely, your browser won’t recognize the certification and present a warning. Bypass the warnings and set an exception for this IP address.

Alternately, you can bypass the warnings but not set an exception and enter your own certificate once you are in the Admin portal:

Use your admin login (again, http://IP_ADDRESS:9090) to access the web interface. One of the first things that you want to do is to create the pool of IP addresses that you want to load balance.

• Click on the icon that says “Services”. You will then see a page with several tabs. Click on the tab called “Pools”. Look for the section that says “Create a new Pool”. First you will want to enter the IP address of the backup server in the US-East-1 Data Center. I have one setup using port 80 and I am calling the pool “East”. You can also set the type of monitoring you want against the pool. Since these are web servers, I am selecting “Simple HTTP” – this ensures that the web server is up and running. For example, if you use Ping, this tells you that the server is responding but not necessarily if the web server itself is down. The click “Create Pool”.
• Next, go back to “Create new Pool” and enter the IP addresses of the two VMs that contain your website in US-West-1 and set the port (typically 80). Give it a name – I am going to call this one, “West1″. Set the monitor here to “Simple HTTP”. Click “Create Pool”. You will now see an option to set the Failure Pool – enter the first pool that you create (“East”).
• Below Basic Settings is a section titled “Load Balancing”. You can also set the algorithm here – in this case, I set Round Robin which will attempt to balance traffic evenly between the nodes.

Next you will want to create a “Virtual Server” (Zeus’ terminology) which means to create a Traffic Manager (TM) instance on your server. Click on the “Virtual Servers” tab to create one. I have created one called “Clustered_TM”. Since I am balancing Web servers, I have set the Internal Protocol to “HTTP” and the Port to “80”. Note the Default Traffic Pool – this is the pool of web servers that I just created (“West1”). Set Enabled to “Yes” and hit the “Update” button to activate the load balancer.

The Zeus TM constantly monitors health so if there are any issues with the servers (such as a server no longer responding) in the pool, it will report it on the main page. Zeus can use different types of checks – in addition to ping, you can also check HTTP, DNS, FTP and others.

You may notice a few warnings when you setup Zeus. Here are some tips to help clear them.

1. Java: Cannot start Java Runner, program ‘java’ not found
   • Go to the System icon and click on the “Global Settings” tab. Scroll down to the Java Extensions bullet and select “No” for java!enabled. This is really only used if you are coding in the API and not if you are working via the UI.
2. Cannot Bind to Port 80
   • This is typically due to Apache2 running on Ubuntu. This should already be disabled by default but you can also manually stop it. SSH into your Zeus VM and enter: service apache2 stop

In this configuration, two servers are handling traffic evenly in the West. If one of the servers in the West nodes should fail, then the load balancer will send traffic to the server that is still running. If both should fail, the failure pool will activate, and traffic will route to the East server. Note that due to the distance from the West load balancer, there will be latency, however this will ensure that the website will still run even if there are issues with both servers in the West region.

Another useful feature is the ability to track activity and connections on the load balancer. First, click on the “Activity” icon and then the “Connections” tab. Since both the West servers are up and running, you can see that the traffic is balancing between those two servers.

Clustering

The previous section only demonstrated setting up Zeus as a single instance. Zeus gives you the ability to setup a clustered pair, in order to provide coverage should one of the Zeus instances go down.

In order to build a cluster, you will need to configure a few things. First deploy a second instance of the Zeus image.

You will need to make some manual changes to the VMs first.

1. SSH into your first Zeus server.
2. Change to the proper directory: cd /etc/
3. Edit the hosts file and include an entry for the second Zeus server that you just deployed
   • i.e. (173.1.45.149 31852-1-67347) in the example
4. Save and Exit
5. SSH into your second Zeus server
6. Edit the hosts file and include an entry for the first Zeus server
7. Login to the GoGrid portal and restart both servers.

These steps make it easier for the Zeus servers to talk to each other. After the servers have restarted, go to the Admin page and run the following steps:

• Click on the System icon and then the “Traffic Managers” tab.
• Scroll down to the bottom and select “Join a Cluster”.
• You will be presented with a Wizard that will guide you to adding the server to a cluster. Follow the instructions on the Wizard to join a cluster (it should auto-detect other Zeus instances in your VLAN).
• This screenshot shows an existing cluster member since I already have this server as part of Zeus cluster.

Once the servers are in a cluster, they will share configurations so you can administer the cluster from either server.

The last step is to make the cluster invisible to the end user. You will need to use an additional public IP in order to do this. Click on the Services icon. Select the “Traffic IP Groups” tab.

Give the Traffic IP Group a name. In this example, I have created one called “Cluster_Traffic”. Add an unassigned public IP address. (IP addresses can be found within the List view under the Network section within the GoGrid portal.) Note that this is a Zeus setting. Even though it will be “taken” by Zeus, the GoGrid portal will still show this IP address as Unassigned.

You can then use this IP address as the outbound IP for your web cluster. It will leverage the use of both Zeus load balancers, automatically and transparently managing failover and traffic.

Zeus gives you the flexibility to launch load balancers as you need them and to directly manage as many server pools as you require. Although load balancing across data centers is possible, latency will not make this an elegant solution – you will need to implement global load balancing. Contact Zeus if you are interested in using this option. If you want to learn more about Zeus, you can get additional information and support from www.zeus.com/community/documentation.

In this blog post series, I want to take a closer look at a storage technology called Gluster File System, and how it can be set up (this article), connected to (article #2) and expand storage (article #3). This is the first blog post of the series and I will review what GlusterFS is, why you would consider using it, and how to deploy it using the GoGrid GlusterFS Partner GSI.

GoGrid offers a great storage solution called Cloud Storage. But what if you want to deploy your own storage so that you can directly control performance and redundancy? What software would you use to provide this? The simple answer is Gluster. It is a powerful software-based storage solution that offers a centralized controlled storage pool management system that is very easy to use.

There are many different ways to take advantage of the GlusterFS storage solution. (Note: in the descriptions below a “brick” is a GoGrid Virtual Server.)

1. Distributed Volumes:

“Distributed volumes distribute files throughout the bricks in the volume. You can use distributed volumes where the requirement is to scale storage and the redundancy is either not important or is provided by other hardware/software layers.” – Gluster.org

2. Replicated Volumes:

“Replicated volumes replicate files throughout the bricks in the volume. You can use replicated volumes in environments where high-availability and high-reliability are critical.” – Gluster.org

3. Striped Volumes:

“Stripes data across bricks in the volume. For best results, you should use striped volumes only in high concurrency environments accessing very large files.”

These storage volume options seem very familiar, don’t they? Well, if you are familiar with the different RAID configurations of hard drives in server deployments, you will notice similarities with these options. For example, the “Distributed Volume” for Gluster is essentially a RAID 0. You sacrifice redundancy to gain superior performance and ease of capacity scaling.

The Replicated Volume is similar to a RAID 10 or RAID 1 where data integrity, redundancy and reliability are very important. However, the cost to scale is more since you need to basically add GoGrid Virtual Servers (bricks) in pairs to maintain the Replicated Volume structure.

The Striped Volume is similar to RAID 5 where data is striped across the GoGrid Virtual Servers (bricks). This comes in very handy when you are dealing with very large files (multiple GB files) and when the file is accessed multiple servers will stream the data to the web-server needing the file – offering very fast reads.

For my blog post, I am going to configure a 4 server Distributed Volume Gluster setup using the GoGrid Gluster Partner Image. I am going to deploy 4 x 8GB Gluster servers. Each Gluster server will have 384GB of storage available. In the Distributed Volume setup (similar to RAID 10), I will have 384GB x2 worth of space equaling approximately 768GB of usable space.

First step is to deploy the 4 new GoGrid Gluster Virtual Servers using the GoGrid Partner GSI. I log into my portal and then follow the next steps:

1. Click “Add”

2. Choose “Cloud Server”

3. Filter for “Gluster” & choose that image

4. Accept the Terms

5. Fill in the server information (name, public IP, description, memory allotment)

6. Repeat this process 3 more time but using different server name and public IP address.

Once you have all 4 of your new Gluster servers deployed, you can then view the Support → Passwords page in your portal to find the login information. With this login information, you can run this command from your local Linux workstation to change the hostname, set the private IP address and reboot each system. Run the following Bash script from your Linux workstation. The script will prompt you for the server address and root login, and also ask for the hostname and private IP address/netmask you want to use. If you don’t want to use this script, simply log into each system manually, update the host names and private IP addresses, and then reboot.

https://github.com/sepulworld/Remote_Linux_System_Update/blob/master/system_update.sh

I should now be able to log into all 4 systems and see the appropriate hostnames and IPs on each.

This looks good – if you don’t see the right hostnames or IPs on one or more of the systems, double check what is configured in the /etc/sysconfig/network file and in the /etc/sysconfig/network-scripts/ifcfg-eth1 file. Also, confirm if your host performed the intended reboot (this is necessary for the host name to update at the command line).

From one of your Gluster servers, confirm private network connectivity by pinging each of the other Gluster servers via their private IP addresses. See image below.

Once this has been confirmed, we can take a look and see if the Gluster process is already running. It is configured on this GoGrid Partner Image to start on boot.

Now I need to configure the trusted server storage pool. Basically, I log into just one of my 4 Gluster servers (I choose Gluster_1) and I run a single command to put each of the other 3 members into the trusted server storage pool.

[root@Gluster_1 ~]# gluster peer probe 10.129.151.107

See image here -

Next, I run the command to create the distributed volume using my 4 Gluster servers.

command: gluster volume create DataStore1 replica 4 transport tcp 10.129.151.105:/store1 10.129.151.98:/store2 10.129.151.108:/store3 10.129.151.107:/store4

You can name the directories anything you want. I used “store1” thru “store4”. You can also name the volume whatever you would like. I choose DataStore1.

Now let’s start the Volume with one simple command: gluster volume start DataStore1

And finally let’s view the volume information: gluster volume info DataStore1

Helpful link:

http://gluster.com/community/documentation/index.php/Main_Page

If you run into any issues or have questions about the Gluster Partner GSI, please email gogrid-beta@gluster.com

That is it! You have successfully deployed the GoGrid Gluster servers from the GoGrid Partner GSI and configured 4 of them in a new replicated storage volume. My next blog post will cover deploying a web-server and connecting to this new storage volume. The third and final post will cover how to scale your replicated storage volume on GoGrid.

I hope you found this tutorial helpful. Stay tuned for Parts 2 and 3. Please let me know if you have any questions.