Eucalyptus Certified Professional - Part 1 - Redefining How Certification is Done

If you pay attention to Eucalyptus press releases (and c'mon, who doesn't?) then you're already aware that Eucalyptus Education is on the cusp of releasing our first major certification in the next couple of months. While that's exciting all on it's own, I'm personally even more excited about some of the major innovations we're making in terms of high-stakes certification exams, and want to bring some of those to light so that you can be prepared, and maybe even help us launch by participating in the beta program. If you're not already part of the Eucalyptus community mailing list, you might want to join soon so that you'll be the first to know... :)

So what makes the Eucalytpus Certified Professional and Eucalyptus 3 (EUCP3) so different than similar  entry-level certifications from vendors like Cisco, SNIA, VMware, CompTIA, Microsoft, EMC, and dozens of other technical certifications? There are several things, actually, and over a few blog posts we'll highlight different ones, explain what we're doing, how it's different, and why we believe that makes the EUCP3 special. Some of the big ones we might discuss are:

Delivery method: The EUCP3 will be available globally via remote, secure, proctored delivery technology. You can take the exam from your home computer (and yes, it's still secure, just as if you took the exam in a Pearson/Vue or Prometric testing facility) as long as you have a web cam with a long cable and a microphone for VoIP audio.

Support resources during the exam: The EUCP3 will be the first certification of its kind that will be delivered in an open-book, open-notes format. You will be allowed to reference any printed material you like, short of printed copies of actual test questions (and even those won't be as much help as you might think... see below...) In the real world, you have complex problems, and you have access to external resources. We believe your testing environment should work in much the same fashion.

Test question development protocol: The reason we can allow remote delivery with open-book, open-notes is because of the way we are developing the certification test items. The questions are going to be more complex than some certifications, just like real-world issues you might run into, and you're going to be required to put knowledge pieces together rather than regurgitate memorized facts and numbers. We strongly recommend that you learn practical things about the software and know where to look for minutia if you need it.

Study guide and practice exam: One thing that always bugs us about certification practice tests is that they usually have nothing in common with the actual exam, and how well you do on them has no bearing on how well you'll do on the exam. Well, we're going to give you a practice exam that gives you questions that will mirror actual test questions, and you'll have a good idea about what to expect on the actual exam. Not only that, we're going to provide you with the complete format of the more complex questions and show you exactly what variables we might change in order to determine or change the correct answer from one form of the question to the next.

The skeptics may say that all of this is going to equal an exam that is too easy, or easy to cheat on. We welcome those skeptics to participate in our beta program when it is announced. This exam has been designed from the ground up to reflect real-world knowledge and skills, in as close to a real-world setting as a multiple-choice exam can get. The item development method is designed to thwart would-be cheaters *even if they have a copy of the entire question bank prior to taking the exam,* so if you're considering paying someone for copies of test questions or getting help from others on the Internet who violate the rules, you should be aware we have designed our questions so that the cheating is likely to do you more damage than good.

Bottom line: If you know the technology well, based on reference documentation and certification blueprint we will provide, you should have no problem earning the EUCP3 certification. If you try to get by on minimum study and rely heavily on your notes, or worse, you try to cheat in order to pass, you're likely going to be disappointed with your results. That's the way a certification should be, wouldn't you agree?

What do you think - does this sound too unrealistic? Are you thinking about participating in the beta? Do you have questions about the exam?

For some additional general information about the program, visit the EUCP3 Certification landing page. To join the Eucalyptus community mailing list, visit our mailing list page.

Why we don't get on-premise IaaS (insights for insiders) - Part 1

Having been an employee at Eucalyptus Systems, Inc. for nearly a year now, I finally can say I get the cloud. I understand the concept, the benefits, the use cases, the technology (*whew*), and how to implement it in the real world (*double whew*). It is also very clear to me that I am in a distinct minority among technical gurus worldwide. Most people just don't get it, and there are some very good reasons for their confusion. I'm not sure there are any great answers to these reasons, but you can't fix a problem if you don't acknowledge it.

Problem #1: No easy ways to build a value proposition based on non-cloud experience.

When I teach our Cloud Connections: Cloud Foundations course, I spend more than an hour on the introduction to cloud computing, carefully building the scenario from the way IT organizations run today, virtualized or not, to how cloud technology and concepts layer on top of that to provide transformational benefit. I can get away with this in a technical training class where I've got lots of time, but in our sound-byte, "give me the overview" society of overly busy technical decision makers and IT professionals, you don't get that kind of time outside of the classroom. What happens then is the creation of a number of catch words, buzz phrases with specific meanings in the cloud, and "quick fix" webinars (admittedly by Eucalyptus and our coopetition as well) designed to convince the world of the benefits of cloud but without providing a foundation for those benefits that the user can frame internally. This leaves folks with a sense of being sold rather than educated, and/or with a vague sense of the value proposition but with no concrete ideas about what to do with it and why they should move, and move quickly. This is a significant problem for the industry today.

I spent many years in VMware education prior to joining Eucalyptus. Virtualization, when I started there, was still a relatively unknown technology, but we could explain a key and major component of the value proposition in just a few words: Virtualization allows you to run multiple "virtual servers" at one time on the same physical hardware, allowing you to dramatically reduce the money you spend on physical IT assets. We'd show you a picture of a physical server with several little virtual servers running on top of it, and for most people the value proposition was immediately clear, even if they were skeptical of the technology itself. They understood servers, low utilization, the need to separate applications, and the problem of datacenter sprawl before we gave them any information, and they could build on that knowledge to immediately understand what virtualization would provide to them.

We don't have that easy, quick, clear value proposition with cloud computing in general, and IaaS in particular. We can talk about elastic resources, but then we need to explain what elastic means (and it means different things in different contexts... yuck...) We can talk about IT automation/consolidation, but then we have to explain why and how that's different from current processes and explain why we don't think that will threaten the livelihood of the person to whom we're talking. We can talk about application resiliency, decentralized management and control, security, disaster recovery, storage-as-a-service, "cloud bursting," and any of the other potential benefits cloud computing provides, but if we just use the buzzwords and catch phrases - and we do that a *lot* - the listener is again left with nothing more than a vague idea about the general idea of the cloud, and worse yet, potentially left with a threatening view of how the cloud might affect their livelihood if implemented in their company. What we desperately hope is that folks will be convinced enough by our salesmanship to explore further, but even then we don't have a lot in place today for them to hold onto as they make those next steps.

What we need to do is figure out the IaaS equivalent of server consolidation for virtualization and distill it into a short sentence that people with no prior cloud experience can understand within about 3-5 seconds of hearing it and seeing it illustrated. Either that, or every IT person on the planet needs to take the time to view the free Cloud Connections: Cloud Foundations (Free) recording available on Eucalyptus University. :)

Can you come up with a short sentence that encapsulates the primary benefit(s) of on-premise IaaS (private cloud) that could be easily understood by someone not already enmeshed in cloud concepts?

Eucalyptus Platform Concepts - Security

Eucalyptus provides two primary mechanisms for instance security: Availability Zones, and Security Groups.


Availability Zones

An Availability Zone is a subset of the cloud (typically a collection of servers and storage) that shares a local area network. An Availability Zone receives a fixed amount of resources, and those resources can be controlled via quotas and access control lists.


Availability Zones vs. Clusters


A Cluster is a group of servers that provide resources to an Availability Zone. Clusters consist of a grouping of resources that are separated for administrative or technical reasons. Administrative reasons might include server ownership or compliance rules. Technical reasons might include different quality of service (QoS) requirements between users, a single cloud managing resources across different distributed datacenters, or the decision to deploy multiple hypervisors. A single cluster can only manage one hypervisor type.

As of this writing, in Eucalyptus there is a 1:1 relationship between Availability Zones and Clusters. Each Availability Zone can have only one Cluster Controller (CC), and if you must configure a separate Cluster, it will exist in a separate Availability Zone.

The two concepts are not inseparable. An Availability Zone is an administrative distinction, whereas a cluster is a collection of physical resources. In the future, you may be able to configure an Availability Zone that contains multiple clusters, if such a design was beneficial.


Security Groups


Security Groups are sets of networking rules applied to all virtual machine instances associated with a group. They define access rules for all instances that are part of the group - for example, accessible ports - and are in effect a firewall.

When a virtual machine instance is created, it is assigned to a default security group that denies incoming network traffic from all sources. Multiple security groups can be configured to allow multiple levels of security based on application needs.

For example, Susan has a multi-tier application that includes a Web Server front-end, an application server, and a database server. The web server needs to be accessed through Port 80 and Port 443. The application server might need to be accessible to the web server and on the internal network through Port 22. The database server might not need to be accessible at all other than through the application server. This can be accomplished by configuring three separate security groups with the appropriate rules.

This concludes our discussion of Eucalyptus platform concepts. In our next blog post we'll transition into a discussion around Eucalyptus architecture.

Eucalyptus Platform Concepts - Storage

Eucalyptus clouds utilizes three types of storage: virtual machine ephemeral storage, cloud bucket-based storage, and Eucalyptus Volumes. Furthermore, Eucalyptus provides the ability to create volume snapshots.


Ephemeral Storage

When a virtual machine instantiates, all of its default virtual disks that are created on the node controller are temporary, or ephemeral. This means that if a virtual machine reboots, any data stored on that virtual machine's disks will not survive.

For cloud-designed, loosely-coupled, dynamic applications, this presents no problem. Data that requires permanence is stored somewhere outside the instance, or else on a Eucalyptus Volume.


Bucket-Based Storage


Eucalyptus provides bucket-based storage through a component called Walrus. Bucket-based storage is permanent storage that is shared across the entire cloud infrastructure, and potentially used by users outside of the cloud as well. A bucket holds an object, which is composed of a file and a metadata file that describes the object.

It may help some readers to think of buckets as analagous to folders or directories in typical operating systems.

In Eucalyptus, bucket-based storage primarily stores Eucalyptus Machine Images (EMIs) and Eucalyptus Volume snapshots. It can also be used for almost any type of data file when Walrus is deployed as a Storage as a Service solution.


Eucalyptus Volumes

Eucalyptus volumes are synonymous with Elastic Block Storage (EBS) volumes in Amazon Web Services. They are permanent storage that can be mounted as devices by Eucalyptus instances. These storage volumes behave like raw, unformatted block devices - or just like hard drives. You can create a file system on top of a Eucalyptus volume, or use them in any other way you would use a block device.

Eucalyptus volumes are configured in an Availability Zone, and can be attached to instances in that same Availability Zone. Multiple volumes can be mounted to the same Eucalyptus instance. Eucalyptus Volumes can also be attached to new instances via an administrative interface.


Volume Snapshots

Eucalyptus provides the ability to create point-in-time snapshots of volumes, which are moved, or persisted, to bucket-based storage (Walrus) for long-term storage. By default, these volume snapshots are crash consistent, meaning that any data marked as written to the disk that still resides in a buffer will not be part of the snapshot.

It is important to note that snapshots in the context of a Eucalyptus cloud are for Eucalyptus Volumes only. The virtual machine instance itself is not backed up during the snapshot process. The instance is assumed to be disposable and easily replaceable, so to behave any differently would be to waste storage resources.

In our next post, we'll look at security concepts in Eucalyptus.

Eucalyptus Platform Concepts - Networking: Network Modes

Eucalyptus cloud networking modes address two basic questions: Who assigns IP addresses? Can I use advanced features, like VLANs and Security Groups?

The networking modes supported in Eucalyptus are SYSTEM,STATIC, and MANAGED (plus MANAGED-NOVLAN).

SYSTEM Mode

SYSTEM is the default networking mode for Eucalyptus clouds. It assumes that virtual machine instances will be assigned IP addresses by an external DHCP server. Eucalyptus clouds in SYSTEM mode can not use Elastic IPs, Security Groups, or VLAN tagging. It is most often used in setting up test environments or proof-of-concepts (POCs).


STATIC Mode


Static networking mode assumes there are no other DHCP servers on the network. Advanced features such as VLAN tagging, Elastic IPs, and Security Groups are not available. The Eucalyptus cloud assumes responsibility for assigning IP addresses to instances. To do so, each IP address must be manually configured and assigned to a specific manually configured MAC address. Because of the labor-intensive nature of STATIC mode, it rarely gets used, and primarily exists for backwards compatibility reasons.

MANAGED Mode


The two MANAGED networking modes are the most common mode in Eucalyptus cloud deployments. In either of them, the Eucalyptus cloud assumes responsibility for assigning IP addresses to virtual machine instances in a controlled subnet, regardless of the presence of a DHCP server on the corporate network. In addition, the user can configure Elastic IPs, and Security Groups can also be used. The only difference between MANAGED and MANAGED-NOVLAN is that MANAGED mode can utilize VLAN tagging for virtual machine instance isolation, whereas MANAGED-NOVLAN can not.

In the next post we'll discuss storage concepts in Eucalyptus.

Eucalyptus Platform Concepts - Networking: IP Addresses

Networking in Eucalyptus requires understanding of three different types of IP addresses and four different networking modes. In this post, we'll take a look at the different IP addresses and what they do.



Eucalyptus clouds deploy three different types of IP addresses: public, private, and elastic.


Public IP Addresses


Public IP addresses are probably the easiest IP address to understand in Eucalyptus. These are the outward-facing IP addresses users use to communicate with their virtual machine instances. These are not allocated directly to the virtual machines - rather, they are mapped IP addresses stored in an iptables database on the Cluster Controller (CC). The CC routes traffic intended for the Public IP to the Private IP address of the virtual machine to which it is assigned.

• Try not to confuse the concept of a Public IP address in the cloud with the concept of a public IP address on the Internet. In Internet terms, a public IP address is a publicly routable address, whereas a private IP address is non-routable and requires Network Address Translation (NAT) in order to communicate with the outside world. In cloud terms, a Public IP address is whatever address a user might use to connect directly to a virtual machine instance. If that user is on your internal network, the cloud Public IP address might very well be in a non-Internet-routable private IP address range. For example, an instance can be assigned a cloud Public IP address in the 192.168.xxx.xxx range, which is a non-routable or private IP address in Internet terms.

Private IP Addresses


The Private IP address is the actual address the virtual machine receives, and the only one of which it is aware. Virtual machine instances also use cloud Private IP addresses for internal networking purposes. They must be configured on a separate subnet from the Public IP address range. For example, if Public IP addresses are configured in the 192.168.xxx.xxx range, Private IP addresses might be configured with a range of 10.xxx.xxx.xxx to avoid any chance of overlap.


Elastic IP Addresses


Elastic IP addresses are permanent Public IP addresses that can be mapped to different virtual machine instances by a user. This mapping allows a user to provide a publicly available service - such as a web site - with an IP address that never changes, even if the underlying virtual machine instance and its associated Private IP address changes.

For example, assume Susan has a CentOS 5.x web server at mywebsite.com, and she has configured it with an Elastic IP address. The actual IP configuration might look something like this:

Let's say Susan wants to upgrade the web server to CentOS 6.x. First, she would set up the new web server - a new instance in the cloud - and test it to make sure it was working properly.

Once she was satisfied that everything worked as it should, she would then re-map the Elastic IP address to the new server.

No changes to public DNS are required to make this change. The Eucalyptus cloud manages everything behind the scenes.

If something went wrong at this point, Susan could re-map the Elastic IP address back to the old web server, and the change would happen instantaneously. If, however, everything continues to work as expected, Susan can decommission the old server, and the upgrade would be complete.

In the next post, we'll continue our discussion of Networking concepts and define the Network Modes currently available in Eucalyptus.

Eucalyptus Platform Concepts - Virtual Machines

A Eucalyptus cloud deployment utilizes a number of important concepts surrounding virtual machines, networking, storage, and security. We'll start with virtual machine concepts.


Eucalyptus virtual machine concepts that are important to understand include Eucalyptus Machine Images (EMIs), virtual machine instances, and virtual machine types.


Eucalyptus Machine Images

A Eucalyptus Machine Image (EMI) is a copy of a virtual machine bootable disk stored in a central cloud storage repository known as Walrus. Some people find it useful to think of them as virtual machine templates from which multiple identical instances - or copies of the virtual machine - can be deployed.
They are analogous to Amazon Machine Images (AMIs) in AWS - in fact, any of the 10,000+ AMIs available in AWS can be downloaded and deployed as EMIs in a Eucalyptus cloud without significant modification. While it is possible for a user to build their own EMI, it is usually simpler to find a thoroughly vetted, freely available image in AWS, download it to their Eucalyptus cloud, and use that instead.

EMIs can be Linux or Windows-based. When copied into a Eucalyptus environment, each distinct EMI is given a unique ID for identification, and a user can add additional descriptive tags for easy identification purposes.


Virtual Machine Instances

A virtual machine deployed from an EMI is known as an instance. An instance, then, is simply a running copy of an EMI. They can start and terminate in a programmatic, elastic fashion based on resource demands. In addition, they attach to storage and networking resources dynamically based on credentials provided to them.

Virtual Machine Types

Virtual machine types control what happens when a particular EMI is instantiated or deployed. The type definition specifies things like the number of CPU cores, memory capacity, and disk capacity that will be given to an instance upon instantiation. Thus, multiple Linux instances of varying size can be deployed from the same EMI. It is not necessary to create different templates just to specify different levels of resource availability.

In the next blog post, we'll look at networking concepts in Eucalyptus.