Cloud Computing

Cloud Computing is a term used to describe a service where Processor, Storage and Networking (bandwidth) resources are available to users over the Internet. The Cloud Compute services are used to run both Server Applications such as Microsoft Exchange, and Client Applications such as Virtual Desktops. There are two types of Cloud Computing being developed today.

1. Virtualization based Clouds (for example, Amazon EC2)
   
   • The application software, for example Drupal CMS, runs in its own Virtual Machines. The OS is not shared with any other application in the cloud. Each customer of this type of Cloud Computing can have their own preferred version of the OS and libraries.
   • Cloud Service Providers provide efficient and high quality ways to host these Virtual Machines
   • Cloud Application Developers develop their server applications in single-tenant mode, i.e. each server application is capable of providing service to one customer company only.
   • A Virtual Machine can contain any fully functional server software. In other words, it can contain applications that were not specifically designed for cloud computing. The following are examples of such software
     • an Microsoft Exchange VM: Contains Windows Server 2003, Exchange and any other add ons to Exchange.
     • a Linux based Drupal Content Management Server: Contains Linux, a web server and application server (e.g. apache, tomcat), an application written in any scripting language such as php, ruby,  python etc. and a database (typically MySQL)
   • All the required software is installed in this VM, that is, it is fully self-contained. A zip or tar file of such a VM is called a Virtual Appliance
   • Applications can be moved from one Cloud to another, maybe from the Cloud back to the Corporate Datacenter, etc.
2. Application based Clouds (for example, Google’s App Engine, Salesforce.com’s force.com)
   • Applications may share the OS that they are running on with other Applications. This results in various restrictions in terms of what OS and libraries the customer can have access to.
   • Applications must be custom developed for the specific cloud.
   • Applications must be developed using specific languages that the cloud supports, for example, Google Apps must be developed in python
   • An application developed for one cloud cannot be moved to another provider’s cloud. Customers are locked in.

Thinsy develops software for the Virtualization based Cloud Computing market. A typical Virtualization based Cloud has the following three aspects:

• Infrastructure Software and Hardware
• Virtual Appliances (fully self contained zip files that have an OS+Apps)
• Operations manpower to run the Cloud

2.1. Cloud Infrastructure Software and Hardware

• Servers - Standard x86 Servers. e.g. a two Quad Core Processor server with 24GB of memory and 4 or 6 250GB SATA disks
• Networking gear - Gigabit ethernet switches, routers etc. Each server may have 2 gigabit network cards
• Hosting and Bandwidth - Datacenters with enough Internet connectivity where these servers are installed
• Software that runs on these servers - For Virtualization based Cloud Computing, the Infrastructure software is VM Servers and VM Management Servers. Examples of such software are VMware ESX and VMWare Virtual Center or EnSpeed VMM with LiveSync and EnSpeed VM Orchestrator

2.2 Virtual Appliances

A Virtual Appliance is a zip file that contains the files necessary to make a Virtual Machine. The Virtual Appliance zip files is a fully self contained  image that contains an OS, an application, maybe a database, and anything else that the application may require.
The process of Virtual Appliance Development may be described using the following steps:

• Create a blank VM on a VM Server by specifying disk and memory (for example, two 8GB virtual disks and 512MB of memory)
• Use an OS ISO image (for example, a CentOS iso) to install the CentOS on the blank VM
• Install mysql database on the Virtual Machine
• Install apache in the VM
• Install php and any other language needed (for example, a JDK for Java development)
• Install the application itself (Drupal, SugarCRM, or Alfresco)
• Customize the application for the specific target market (TimeZone, language, etc.)
• Add any GUI that you need for administering the Virtual Machine. All of our EnSpeed Virtual Appliances have a GUI for configuring the IP address, etc.
• Copyback the VM from the VM Server back to the EnSpeed VM Orchestrator to make a Virtual Appliance

Once the Virtual Appliance has been created, then you can make any number of Virtual Machines using this Virtual Appliance.
The EnSpeed VM Orchestrator provides an intuitive GUI to perform all of the actions described above.

2.3 Operations Manpower to run the Cloud

Once you have Virtual Appliances, you can sell these services to your customers. Every time you get a new customer, you create a new Virtual Machine using the Virtual Appliance of customer’s choice and start up the VM. The Operations team now steps in and runs the VM. The tasks involved typically are:

• Monitor VM servers to ensure that they are running smoothly
• Monitor VMs to ensure that they are providing services
• Take backups of the VMs at regular intervals

http://weblog.infoworld.com/storageadviser/archives/2008/09/taking_a_global.html

It talks about the likelyhood of cheaper SSDs.

There is one point I would like to make regarding SSDs - they have very low seek times. This means that you do not need an array of disks to sustain high throughput from the disk subsystem.

To us here at Thinsy, this is good news. If you do not need to connect to an array of drives to get the throughput for multiple VMs, then the only reason left to move storage to a SAN is for high availability. Our technology eliminates that last reason as well. We synchronize the virtual disks from one server on to another. This means we can do High Availbility without a SAN.

1. Fully SSL encrypted web based interface. Bring your Windows, Apple and Linux based browsers along - all Orchestrator functions work just fine. No client software installation necessary.
2. Fully componentized architecture. It’s very easy to extend, and to write applications on top of.
3. Built in multi user capabilities. If you have a few VM servers available, and want to allow users to create VMs and experience the power of virtualization, this is the management server for you. We designed this software with VM Hosting Service providers in mind.
4. Our Orchestrator is the only VM Management server that is aware of P2P Synchronized storage. This is a nifty feature. You can provide Enterprise quality VMs using plain old Direct Attached Storage - SATA, SAS, IDE all work fine.

Our Zen approach to VM Management has resulted in a simple and elegant VM Management solution. Best of all, it is free for end users, i.e. if you are not a service provider selling hosted VMs, you can use this software for free. Download it, and give it a whirl..

In our newly released 0.9.9 version, we have secured all connections (including the connection from the java VNC Viewer applet) using SSL.

• LiveSync Support for Oracle VM Server 2.1.1
• Clone VM support
• Fully secure SSL connections to the VM Orchestrator.

Go ahead, download this release and give it a whirl.

 For Centos 5.x

1. Edit /etc/X11/xorg.conf as follows:
   1. In section ServerLayout, add:
      1.     InputDevice    “Tablet” “CorePointer”
             InputDevice    “dummy”
2. Add two sections
   1. Section “InputDevice”
          Identifier    “Tablet”
          Driver        “evdev”
          Option          “Device” “/dev/input/event2″
          Option          “DeviceName” “touchscreen”
          Option          “MinX” “0″
          Option          “MinY” “0″
          Option          “MaxX” “32256″
          Option          “MaxY” “32256″
          Option          “ReportingMode” “Raw”
          Option          “Emulate3Buttons”
          Option          “Emulate3Timeout” “50″
          Option          “SendCoreEvents” “On”
      EndSection

      Section “InputDevice”
          Identifier “dummy”
          Driver “void”
          Option “Device” “/dev/input/mice”
      EndSection

For Centos 4.x

1. Download the evtouch driver from http://stz-softwaretechnik.com/~ke/touchscreen/evtouch.html#download
2. cp evtouch_drv.o /usr/X11R6/lib/modules/input
3. Edit xorg.conf as follows:
   1. Add to the ServerLayout section
      1. InputDevice     “Tablet” “CorePointer”
      2. Remove CorePointer from - InputDevice    “Mouse0″
   2. Add new section
      1. Section “InputDevice”
             Identifier    “Tablet”
             Driver        “evtouch”
             Option          “Device” “/dev/input/event2″
             Option          “DeviceName” “touchscreen”
             Option          “MinX” “0″
             Option          “MinY” “0″
             Option          “MaxX” “32256″
             Option          “MaxY” “32256″
             Option          “ReportingMode” “Raw”
             Option          “Emulate3Buttons”
             Option          “Emulate3Timeout” “50″
             Option          “SendCoreEvents” “On”
         EndSection

We have had a few bug reports where adding an EnSpeed VMM to the EnSpeed VM Orchestrator fails with a timeout error. This happens if DNS is non-functional in the EnSpeed VMM. The solution to this is to add an entry of the format “nameserver a.b.c.d” to the /etc/resolv.conf file in each of the EnSpeed VMM Servers. In the above example replace a.b.c.d with the IP Address of a DNS Server for your network.

Here at Thinsy, we truly believe that peer to peer disk synchronization with the Storage Intelligence running on the server CPUs is a superior alternative. Intel and AMD are supplying us with more cores per server. Much more than we know what to do with. Let’s put these CPUs to good use. Let’s move storage intelligence back to the servers. Simple Gig (or 10Gig) ethernet connectivity is all we need. 

Here’s a link to the server I’m talking about - http://www.sun.com/servers/x64/x4150/

 – Jagane

PS: I have not really installed and run EnSpeed VMM on these servers. I was just thrilled to see so much disk bandwidth available to me.

 When I set out to build a synchronizing storage system for virtual disk images, I wanted to retain this desirable characteristic of vmfs3. However, I wanted to eliminate the necessity for external storage. Hence, I designed LiveSync to be software that interposes in between disk I/O from Guest Operating Systems to Hypervisors. It operates on individual virtual disk files. COW files are stored as regular files on the underlying file system; they can be redo files or undo files. The base virtual disk image is also a simple file on the underlying file system. This design offers the following benefits:

1. Familiar file system user interface to virtual disk storage.
2. Familiar tools such as tar, gzip, zip, cp, mv, etc. can be used to operate on virtual disk files.
3. Fine grained control over virtual disk images. Virtual disk characteristics can be different for each VM. For example, four VMs residing on a VM Server can have different backup schedules, different undo depth, etc.
4. Unlinke kernel modules, LiveSync development can proceed independent of the Linux kernel. This makes the software much more manageble.
5. LiveSync is much more scalable than cluster LVM. It does not need the servers to be part of a tightly knit cluster.
6. It is easier to write management software for automated placement of virtual disk images, creating full backups, incremental backups, etc. 
7. Remote synchronization over high latency links is feasible.

If you are interested, download and try EnSpeed VMM with LiveSync. It’s operation is very transparent. You can see your virtual disk files, you can manipulate them, etc. It’s not a black box.

1. Full utilization of the hardware in the VM Servers. IDE/SATA/SCSI/SAS controllers and disks on VM Servers are fully utilized
2. Much less intensive Storage Networking infrastructure. (Ethernet for iSCSI SANs and FC for FC SANs).
   1. Each VM Host:
      • SAN: 8x Reads + 4x Writes
      • LiveSync: 4x Sync In + 4x Sync Out
   2. Storage Array:
      • SAN: 32x Read + 16x Write
      • LiveSync: None!
3. No need for complex distributed file systems such as vmfs
4. Storage intelligence (snapshots, backup, smart caching, etc.) moves back to the VM Server CPUs — of which we have plenty. The Storage intelligence is effectively “distributed”. This eliminates the need for SAN heads or NAS heads.