Search Results for: vCD

5 Tips for preparing your VCDX Defense

Duncan Epping · Nov 15, 2010 ·

After the VCDX defenses Boston I had a chat with Craig Risinger, also known as 006 ;-). We discussed some of the things we’d seen on the panels and came to the conclusion that it wouldn’t hurt to reiterate some of the tips we’ve given in the past.

It’s OK to change your actual project documents. See the following points for examples. This isn’t really about what you actually happened to do on a particular project with its own unique set of circumstances. It’s about showing what you can do.This is your portfolio to convince potential customers you can do their design, whatever they might need. It’s about proving you could work with a customer to establish requirements and design an architecture that meets them.
Include everything the Application says is mandatory. Don’t be surprised if you have to write some new documents or sections. For example, maybe a Disaster Recovery plan wasn’t important in your project, but it will be to another customer or in another project, so you should show you know how to create one.
Explain any bad or debatable decisions. Did your customer insist on doing something that’s against best practices? Did you explain what was wrong with it? Say how you would have preferred to do things and why. Even if you just made a mistake back then, that’s OK if you can show that you’ve learned and understand the error you made. If you are using VMware’s best practices make sure you know why it is a best practice and why it met your customer’s requirements.
Show you can design for large scale. It’s OK if your actual project was for a small environment, but show that you can think big too. What would you have done for a bigger customer, or for a customer who wanted to start small but be able to scale up easily? What would you need to do to add more VMs, more hosts, more storage, more networking, more vCenter servers, more roles and division of duties, a stronger BC/DR plan in the future? How would that change your design, if at all?
Architect = Knowledge + Reasoning. The VCDX certification isn’t just about knowing technical facts; it’s about being able to apply that knowledge to meet goals. In the defense session itself, be prepared to discuss hypothetical scenarios and alternative approaches, to decide on a design, and to explain the reasons for your choices. Show you know how to consider the pros and cons of different approaches.

There are also many other useful collections of advice for pursuing a VCDX certification, we highly recommend reading them as they will give you an idea of the process. Here’s just a sample:

Craig Risinger (VCDX006) & Duncan Epping (VCDX007)

vCD – Networking part 3 – Use case 2

Duncan Epping · Oct 6, 2010 ·

Part 1 explained the basic concepts of networking within vCD(VMware vCloud Director), Part 2 focussed on Network Pools and Part 3 focussed on a use case which was a vApp directly connected to an External routed Org Network. It took me a while to develop part 3 and I wasn’t sure if I could find the time to do another use case or not. I received a dozen requests for another use case so I decided to free up some time to help you guys out. Please read the other parts of this series before you start reading this part. Okay, let’s dive into those trenches.

vApp fenced to an Internal Org Network

Use case:

Environments where vApps are copied and redeployed for test and development purposes. There is no connection back to the customers datacenter to avoid any interference that could be cause by these test environments.

We will start with the basics. The flow of the network in this case will be:

Although only two different type of networks are used, this could of course result in multiple layers if and when for instance multiple vApp Networks are created. For the purpose of this exercise we will create a vApp with 3 VMs including two different networks. You could say you classical three-tier application.

WEB = Web Frontend
APP =Application Server
DB = Databaser Server

As you can imagine we don’t need users accessing the Application or Database Server so these two will be on a separate network segment. The Web Frontend will need to be accessible though and it will need to be able to access both the Application and the Database Server. Logically speaking that will look as follows:

Please note that the Org Network doesn’t connect back to anything! This means that in order for you to connect to your WEB vm you will need to go through the vCD Portal! Of course you could still test if your web services are working by simply deploying a desktop VM with windows XP in the same Org. Now I can hear some of you think why not just a NAT-Routed Org Network, well that is something that would work as well, but than it would be really similar to what use case 1 provided and this is purely for educational purposes.

Creating the Networks

The first step of course is to ensure you have a Network Pool. If you haven’t already created, you can use Part 2 of this series as a reference. I am assuming here you already have a network pool and will go straight to the Org Network, which is option 7 on the home screen.

Now you will need to select the Org that this Network will belong to and then you can decide what type of network you will create. You can do this in either “Typical” or “Advanced” mode. Both will give you the same options but it is named slightly different and Advanced will only allow you to create 1 network at a time where with Typical you can create multiple. As we have used Typical in the previous use case we will use Advanced this time. We are going to create a fully isolated Org Network so we will select “Internal Organization Network”.

Next up we will need to select a network pool. Now you might ask yourself why we will need one when the Org Network is completely isolated? Well we will need cross-host communication when vApp/VMs need to communicate with each other and don’t reside on the same host. Although it sounds very logical, it is often overseen that this is what a network pool does. It enables cross-host communication. In this case we will select the vCloud Network Isolation Network Pool.

Now we will need to specify the IP details for this Org Network. These IP addresses will be consumed by the VMs that are configured to use the “static pool”, in our case that will be the vShield Edge device that is deployed as part of this Isolated Network (deployed for DHCP services etc) and the WEB virtual machine.

Of course we will need to give it a name. I tend to use the name of the Org and the type of Org Network I created.

Now we will need to build a vApp. As stated this vApp will contain multiple VMs.

We will give it a name.

And we will start adding multiple VMs to it. The WEB virtual machine will have 2 NICs as it will need to connect to a device outside of vApp and to two VMs inside of the vApp.

The following two VMs “APP” and “DB” will be configured with a single NIC as they will only need to connect to each other, all contained within the vApp.

Now this is the part where we will assign specific network segments to the NICs. For WEB we will connect “NIC 0” to the Internal Org Network and NIC 1 will need to be connected to a vApp Network.

This vApp Network however will need to be created first. Please note that this is a vApp network, so only available to those VMs which are part of this vApp! Again we will need to specify IP details for the VMs to consume.

When we have done this and have given the vApp network a name we can connect the remaining VMs to the same network.

Now in order to have multiple copies of the same vApp running within the Org we will select “Fenced” mode for the vApp which basically will deploy a vShield Edge device.

I guess this diagram that vCD creates makes it a bit more clear what your vApp connectivity will look like:

And if that isn’t enough you can also check the Maps functionality that vCenter offers. This will give you a great view of how this vApp is connected within vSphere.

So what about that desktop? And what about if we have two copies of that vApp running? Well this is what the map would look like if when we have created these. On the middle left you will see the desktop that is used for testing the WEB VMs. Both WEB virtual machines can be accessed through the VSE device, which of course means that you will need to setup NAT, but we will leave an in-depth explanation around that for the next article.

Summary

vCloud Director Network is really powerful, but as shown by this use case it can get very complex rather fast especially when you are using multiple layers. In this example we kept it simple by using an isolated network, an External NAT/Routed Org Network would have added another layer. Features like vCenter Maps will however make it easier to understand what has been created on the vSphere layer to enable these layers of networking, make sure you take advantage of functionality like this when exploring vCD!

Last chance to become a VCDX3!

Duncan Epping · Oct 4, 2010 ·

For those who are currently in progress of obtaining a VCDX certification please note that VCDX3 has come to an end. If you still want to become a VCDX 3 and already passed the Design and Enterprise exam Partner Exchange in Orlando (February 7, 2011) is your last chance.

If you have passed both the VCE310 and VCD310 exams and wish to apply for a VCDX3 certification:

Download the VCDX3 Application & Handbook and prepare your defense for the week of February 7, 2011.

The application will be due on November 22, 2010, at 5:00 PM PST.

The final opportunity to deliver a defense in pursuit of the VMware Certified Design Expert on VI3 (VCDX3) certification will be at VMware Partner Exchange in Orlando, Florida the week of February 7, 2011.

Please note that defense slots are limited and will be reserved for candidates who submit completed applications in the order received.

You have got a month and a half to submit your design, but I would definitely recommend to get it in as soon as possible. Make sure however that your Application Form is completely filled out. There are a bunch of tips to be found here.

For those who think they can still quickly register both exams to become a VCDX3

Registrations for the VMware Enterprise Administration on VMware Infrastructure 3 Exam: VCE310 have been closed. No new registrations for this exam will be accepted.
Registrations for the VMware Design on VMware Infrastructure 3 Exam: VCD310 have been closed. No new registrations for this exam will be accepted.

vCD restart issues

Duncan Epping · Sep 30, 2010 ·

One of my readers had an issue with a vCD cell not starting correctly. He wanted to know how to monitor the progress of the startup of the daemon. You can do that very easy with the following command:

tail -f /opt/vmware/cloud-director/logs/cell.log

Now you should see status updates like the following pass by:

Application Initialization: 9% complete. Subsystem 'com.vmware.vcloud.common.core' started

At some point it should of course say “Application Initialized”. If it doesn’t the cell.log file should give a hint why it hasn’t been initialized. If for whatever reason the issue persists you could always check the “vcloud-vmware-watchdog.log” for details on the dump. There is a great KB article on this topic though, make sure you read it!

Now, what I wanted to use this article for is to document percentage where a start can get stuck and the possible issue that causes it. I have just a one to start with but hopefully this will grow overtime:

9% – Possibly caused by DNS issues

vCD – Allocation Models

Duncan Epping · Sep 22, 2010 ·

Over the last two weeks I received multiple questions about the VMware vCloud Director (vCD) Allocation Models. vCD has three different type of allocation models which are used to allocate resources to a tenant. We will first reiterate some of the basic concepts of VMware Cloud Director before we dive into these allocation models.

vCD is an abstraction layer. vCD is a layer on top of vCenter and abstracts all the resources vCenter manages. All these resources are combined into large pools for cloud tenants to consume. (Read Frank’s excellent article on these resource groups.) Within VMware vSphere clusters and resource pools are used as resource containers. As a cloud tenant is unaware of the technology used underneath vCD has introduced the concept of Virtual Data Center’s (vDC).

There are two different types of vDC’s:

Provider vDC
Organization vDC (Org vDC)

A Provider vDC is a pool of CPU and memory resources combined with the storage resources you selected. A provider vDC can be a VMware vSphere Cluster or a Resource Pool and a provider vDC is the source for Org vDCs. Org vDCs are used within vCD to partition Provider vDCs and to allocate resources to an organization. vCD uses regular vSphere Resource Pools to partition these resources. So each Org vDC corresponds with a resource pool on the vSphere layer. So what is this Allocation Model that we will be discussing? Where does the Allocation Model come into play?

An Allocation Model is defined on an Org vDC level. The Diagram below depicts a scenario where four Org vDCs have been created in a single Provider vDC. The Provider vDC has a 1:1 relationship with the cluster in this case.

Allocation Models

Allocation Models within vCD are used to determine how resources are allocated to the Organization vDC and more than likely how your customer will be charged for these resources. Currently vCD has three different types of allocation models. These allocation models are listed below, with the original description provided by vCD.

Allocation Pool
Only a percentage of the resources you allocate are committed to the organization vDC. You can specify the percentage, which allows you to overcommit resources.
Pay-As-You-Go
Allocated resources are only committed when users create vApps in the organization vDC. You can specify the maximum amount of CPU and memory resources to commit to the organization vDC.
Reservation Pool
All of the resources you allocate are committed to the organization vDC.

Each allocation model has its own characteristics. These characteristics can be placed in two categories:

Virtual Machine Level
Resource Pool Level

The distinction between each of the Allocation Models is how resources are allocated or to use vSphere terminology how resources are reserved or limited. In order to guarantee resources to a VM or to an entire pool vCD will set a reservation. To avoid extreme contention vCD will also cap your resources by setting a limit. These reservations and limits will be set on a VM or Resource Pool level depending on the chosen allocation model.

For each allocation model shown in the screenshot below the characteristics will be broken down in the following sections.

Allocation Pool

This is the default model, the Allocation Pool. This model allows you to specify the amount of resources for your Org vDC and also specify how much of these resources are guaranteed. Guaranteed means that a reservation will be set and that the amount of guaranteed resources is carved out of your Provider vDC. The total amount of resources specified is your upper boundary, also known as your resource pool limit. I think a diagram will explain it a bit better in this case:

Characteristics

Each model as stated before has very specific characteristics. Each of these are listed below:

Pool of resources of which a percentage will be guaranteed
- A reservation will be set to guarantee resources on a resource pool level
- By default the resource pool reservations on CPU is 0% and memory 100%
- Tenant has a guaranteed set of resources and has the ability to burst to the upper limit
VM Level characteristics
- No reservations or limits set on a per VM level for CPU
- Reservations set on a per VM level for memory. This reservation is based on the percentage of guaranteed resources

These characteristics are more in detail explained in the following example.

Allocation Pool example

In the example below the tenant requested 10GHz of CPU resources with a guarantee of 25% and 10GB of memory with a guarantee of 100%.

Note that the default for CPU is a 0% Guarantee which has been changed to 25% on CPU as requested by the tenant. Also note that you can specify the maximum amount of VMs that can be deployed in this org vDC. This will also help you restrict the level of over commitment and will be discussed later.

These settings on a vCD level result in a resource pool with a reservation of 2500MHz and a limit of 10.000MHz. As vCD describes it, 2500MHz are guaranteed and the customer will have the ability to burst up to 10.000MHz. The resource pool that is created and its properties are shown in the below screenshot.

As described in the characteristics section no CPU reservation or limit is set on a VM level which is shown in the following screenshot.

This is different on memory however. On memory both a reservation and a limit has been defined. The limit always equals the provisioned memory and the reservation equals the guaranteed memory as defined of part of the Allocation Model. However, in our example we set the percentage of guaranteed memory to 100% which results in a reservation and a limit of both 512MB.

For the sake of completeness we have changed the guaranteed resources for memory to 50%. Of course the resource pool has changed accordingly. As shown in the screenshot below the reservation on memory has changed to 5120, which “happens” to be 50% of 10240.

This will in its turn also has set the per VM level memory reservation to 50% of the provisioned memory. In the screenshot below the VM was provisioned with 512MB of which 256MB has been reserved.

Summary

As shown in the example the percentage of guaranteed resources will have its impact on the implementation of the resource pool and the limits and reservations associated with these. It is recommended to align the maximum number of VMs with the specified amount of GHz and GB. When limiting the amount of VMs an extreme level of over commitment within the Org vDC can be avoided.

Pay-As-You-Go

This is the model many of you are familiar with and many also adopted in their company, pay-as-you-go. This model allows you to specify the amount of guaranteed resources per VM. When the percentage of guaranteed resources is set to 100% a reservation is set to 100% of what has been allocated that particular VM. Where this model differentiates itself from any of the other models is that it allows you to limit the vCPU speed. By default the vCPU speed is set to 0.26GHz, the impact of this vCPU speed will be shown in example below but be noted that this vCPU speed is set on the VM as a hard limit.

Characteristics

Percentage of resources guaranteed on a per VM level
- A reservation will be set on a VM level
- By default the VM reservation on CPU is 0% and memory 100%
- By default the vCPU speed is set to 0.26GHz, which means you vCPU will be limited to 0.26GHz
The Org vDC resource pool is just an accumulation of all reservations set on a per VM level

These characteristics are more in detail explained in the following example.

Pay-As-You-Go example

In the example below the customer requests an Org vDC based on the Pay-As-You-Go Org allocation model with a vCPU speed of 0.26GHz of which 25% is guaranteed. Memory will be left to the default setting which is a 100% guarantee.

Note that the default for CPU is a 0% Guarantee which I changed to 25% on CPU to see the impact. Also note that the vCPU Speed is set by default to 0.26GHz. This is something that you will want to increase! When the Org vDC is created it results in a resource pool with the following characteristics.

As described in the characteristics when vApps are created the associated reservations will be accumulated into the resource pool. When a vApp is created with two VMs (each having a single vCPU and 512MB of memory) this will result in the following changes, note that both the reservation on memory and CPU have changed.

As can be seen on a Resource Pool level a reservation is set of 130MHz which is 25% of 2 x 0.26GHz. A guarantee of 100% was set on memory which translates to 1221MB in total. (Note that a resource pool includes the Memory Overhead of virtualization. See the Resource Management Guide for more details)

As stated the resource pool is jut an accumulation of all VMs. The following is what has been set on a per VM level, first screenshot shows the CPU details and the second shows the Memory details:

As can be seen a reservation has been set of 65MHz and a limit of 260MHz on CPU. For memory a 512MB reservation and limit has been set. If the “guarantee” on memory is set to 50% than the reservation of memory on this VM would be 256MB.

Summary

The tenant will have guaranteed resources per VM. As shown the vCPU speed defined is the limiting factor for a VM. For user experience it is recommended to select at least 1GHz as the vCPU speed. The resource pool created as part of the Org vDC only accumulates reserved resources and does not limit the VMs. Limits are placed on a per VM level. Please note that if the “guarantee” is set to 100% a reservation equal to the limit is set. In the case of a 1GHz reservation this can lead to very conservative consolidation ratios.

Reservation Pool

The third and final Allocation Model is the Reservation Pool. In this model all resources are guaranteed by default. It could be compared to an allocation pool with all guarantees set to 100% and is fairly straight forward.

Characteristics

Fully guaranteed pool of resources
- A reservation will be set to guarantee resources on a resource pool level
No reservations or limits set on a per VM level for CPU

These characteristics are more in detail explained in the following example.

Reservation Pool example

In the example below the customer requested 10GHz of CPU resources. As stated, the default guarantee is 100%. As can be seen in the screenshot there is no way to dictate the amount of MHz per vCPU or a Guarantee for that matter.

As expected that results in a resource pool with a limit equal to the reservation as shown in below screenshot.

On a per VM level no reservations or limits are set. This is shown in the following two screenshots.

Summary

As shown the Reservation Pool allocation model is fairly straight forward. A limit equal to the reservation is set on a resource pool level which gives the tenant a guaranteed pool of resources. There are no limits or reservations set on a per VM level which gives the tenant a lot of flexibility. However, this flexibility could lead to severe over commitment within the Org vDC. As such it is recommended to limit the amount of VMs to avoid a degraded user experience.

Conclusion

Each of the three allocation models has its own unique characteristics to fit your customers needs. Is your customer looking for a pool of resources of which a chunk is guaranteed so that they can burst while having a fixed price per month and only pay for the burst space when they are using it? Allocation Pool would be the right answer! Do they have very transient workloads and do they only want to pay for these when using it? Pay-as-you-go would be the best fit. Is your customer just looking to expand their Datacenter with a “dedicated” chunk of resources? Reservation Pool does just that.

However, think before you decide which Allocation Model you will use, think about the amount of resources guaranteed and make sure the amount of resources add up with the max amount of VMs that can be deployed in the Org vDC. One of the most important thing when you are selling a service is user experience!

After I wrote all of this one of my colleagues(Thanks Andy!) was so kind to transform it into a table. This says it all in just two simple tables. The first table describes the characteristics on a Resource Pool level and the second on a Virtual Machine level. Enjoy: