Friday, December 20, 2013

Chargeback Design 2/2

I know I own you guys the second part of my Chargeback Design series.
I don’t want this year to come to an end with this pending … let’s wrap it up.

As you might remember from the first post, you can install Chargeback Manager apart from Data Collectors!!

But wait, there’s no VMware Chargeback sizing or architecture guideline out there to help us decide how to build this solution.
I will share with you how architect  your solution with just a few simples questions:

First question: Does it require external access ?
With external I mean something outside of your control and governance, could be the internet, a partner’s network, etc.

If yes, then install the Chargeback Load balancer component only and place the server on your DMZ.

When you install a fresh new instance of Chargeback, the load balancer is installed by default, also it’s the only load balancer solution certified to work with Chargeback.
The load balancer will ensure that each instance of Chargeback Manager will serve an equal number of users.

You might be wondering, what if my load balancer goes down ?!?! 
Well, you lose access to Chargeback Portal. You can mitigate this risk, enabling VMware’s High Availability (HA). In case of any outage, HA will bring the Load Balancer server back in minutes. But, what if I cannot afford an outage of minutes ?!?! You could still use VMware Fault Tolerance (FT) to protect the Load Balancer server, as long as the VM is a single vCPU.

Second question: Does the Chargeback Portal need to be highly available ?
Some companies don’t need it to be running 99,99999% of the time. They are just concerned about monthly billing reports or showback reports that can wait until you fix the server ; )

But if your answer is yes, then you need to install at least 2 instances of Chargeback Manager, and point then to the same database and Chargeback Load Balancer.

 Obs: make sure you install the same version of Chargeback on all components of the solution).
Check the Chargeback Installation Guide about how to install those components and what ports need to be opened to the Load Balancer communicates with the Manager.

 Some Guidelines:
External Access: Place Load Balancer on DMZ
Need for High Availability: N+1 Chargeback Manager
Amount of Chargeback Manager: 1 for each 50 concurrent users

yeah, yeah, what about Data Collectors sizing ?!?! 
We will cover Data Collectors on a third post (that one became to large).



Wednesday, December 11, 2013

Demystifying vSphere Replication 5.5

******                 Updated information - Jun 02, 2015                                 ******
******                   Check new Maximum for VR 6.0                                      ****** *************************************************************************

That’s an updated post of Demystifying vSphere Replication, which was focused on VR 5.1.

While most of the concepts and information’s still true, the release of  vSphere Replication 5.5 brought a few new things!!!
For a total comprehension of the topic I advise you to read the original post as well.

The maximums still the same, but now there’s no difference between the VR that comes with Site Recovery Manager (SRM) or the Stand Alone version, that means you can replicate a maximum of 500 VMs, to load balance the replication you can deploy multiple VR servers up to 10 (that’s the bigger change at 5.5), remembering each one will be limited to a 100VMs.

Operations Limits (KB2034768), has just been updated to reflect this new concept.

A new welcome feature is that now Storage vMotion and Storage DRS are supported on the source VM, not affecting the replication of recoverability at all.

Another new feature is the Multiple Point in Time Recovery, while configuring the replication you can configure how many Point in time you want to keep. After recovering a VM, those Multiple Points will be available as snapshots, which you could revert as your will.

The utilization of additional Multiple Point would cause a need for extra storage on the 
 destination. Plan it carefully.

Tuesday, November 26, 2013

Consuming Messages from RabbitMQ with vCenter Orchestrator

Finally we came to the end of this vCloud on top of vSphere MetroCluster solution.

Let’s review what we have done so far.

Now, let’s see how vCenter Orchestrator can integrate with the messages RabbitMQ receives from vCloud Director in order to automatize the DRS Affinity Groups management.

- Open vCO Client
Make sure the following plug-ins are available and configured

First thing you need to do is to add the RabbitMQ server to vCO.

- Open vCO Client 
- Login against your vCO server
- On Design View
- Expand: Library / AMQP / Configuration
- Run the Workflow Add a broker

- Provide a name to identify the AMQP Server and click Next

- Fill the details with the information about your AMQP Server and click Submit

 Your AMQP server is added to the vCO environment, now we need to configure the queue where the messages will be published by vCloud. It’s done with Subscribes.

- Run the Workflow Subscribe to queues

- Type a name for the Subscription and click Next
 - Click on Not Set to select the broker (AMQP Server) we created on the previous step

 - Click on Not Set to Add a queue

- Type the Queue name you add on RabbitMQ and click Insert Value
- Make sure the name is on the list and click Accept 

- Click Submit

Once you configure the AMQP server and Subscribed to the queue, we need a way to consume these messages on a regular basis. That's accomplished through the use of Policies.

Let’s create a Policy Template instead, that way you can reapply the Policies as much as you can.

- Go to Administer View click on policy templates tab and click add policy template

- Give it a name and click OK

- Click on add policy element

- Select the AMQP Subscription you just created, click OK

- Give it a name

- Click on ad trigger event

- Select OnMessage and click Select trigger

 - Search for the workflow you want to be executed  when a message arrives

- Select the desired Workflow and click Select
Obs: you can use the filter field to help your search

- On the Source parameter select not set

- Select Self and click Select

- Click Save and Close

Now that our Policy Template is created we just need to apply it.

- Right Click your new Policy Template and select Apply Policy

Under AMQP:Subscription, click on Not Set and browse for the subscription you just created.
Then click Submit

- You will be redirect to the Policies Tab, right click your new Policy and select Edit

- Change the field Startup to: On Server Startup, start the policy

- Save and close.

- Start your policy

Congratulations, it’s done !!!!
This policy will be listening to the AMQP queue and once a message arrives there, it will be consumed and the workflow you just set up on your policy will be executed.

Once every project/environment is unique and has it's own requirements, does not make sense to post here my workflow details, nevertheless I will post a screen of mine just in case you are curious about how it would looks like.

It’s up to you now !!!!!

Tuesday, November 12, 2013

Enabling notification on vCloud Director

Today we will cover the easier step on this whole solution
Enabling notifications on  VMware vCloud Director.

When this configuration is enabled, vCloud will send notification of every task executed on it’s environment; creation of Orgs, VMs, vApps, Networks, customization of VMs....
 you got it, right ?!?! it will send notification about EVERYTHING.

On the last post we already configured RabbitMQ to intercept the notifications about VMs creation, therefore it’s just a matter of enabling vCloud to start sending them.

Log on vCloud Portal
Click on Administration

Click on Extensibility

Click on Enable Notifications
Fill the information about AMQP Hostname, Exchange, user and password

Click Test AMQP Connection to make sure it’s all right.

That’s all you need, from now on vCloud will send notification to the AMQP queue.

Since it’s a piece of cake, I will give you guys a bonus !!!!

But remember, It’s not related to the solution I’ve been discussing here.

It’s not unusual that some kind of approvals be required in cloud solutions.
With this in mind let’s see how a request can be paused until some administration approve or reject it.

The process is the same; configure RabbitMQ queues and enable vCloud notification plus the configuration of vCloud’s Blocking Tasks.

Blocking Tasks are notifications about specific actions which are suspended until a system administrator or an automated system  (you need to create it) acts on them, lets take an example of VM’s creation, it can be automatically approved and provisioned unless someone request a 8 vCPUs VM, in this case an approval will be send to the system administrator to approve or reject it.

Once the Notifications has been set up, click on Blocking Tasks

Browse to the list of actions and enable the action you want to block when performed by your users.
It's done.

How easier could it be ?!?!?

Tuesday, October 29, 2013

Configuring RabbitMQ’s queues for VMware vCloud Director

 If you are not following my vCloud adventure, I suggest you go back and read the first post about it ; )

In this post I will cover how to create and configure a RabbitMQ’s queue to receive the messages generated by VMware vCloud Director.

 Since vCloud Director does not communicate, natively, with vCenter Orchestrator, we need some component exchanging information between them, this component, RabbitMQ, will act between VMware vCloud Director and vCenter Orchestrator, exchanging messages about the VMs, so whenever some VM is created on vCloud, it’s information is published on RabbitMQ, so Orchestrator can consume this message and act based on your needs.

 For this integration to work you have to create, within RabbitMQ, an Exchange, a kind of post office that will receive all the messages, and a Queue, a kind of a mailbox, it’s where the messages will be standing up until it’s has been gathered by it’s owner, or should I say it’s application ?!?!?
Let’s go through it

I won’t cover RabbitMQ installation here because it’s very well documented on it’s website: here’s the link for the installation details

Once installed, open RabbitMQ main page and click on “Exchanges”
Then click on “Add a new Exchange”

 Give it a name and select the Exchange Type as “Topic”, leave the other fields as it is and click “Add Exchange”

If you want to learn more about Exchange’s Types, check it in here.  

Click on “Queues”
Then click on “Add a new Queue”

Give it a name, leave the other fields as it is and click “Add Queue”

 Click on the recently created Queue

 Click on “Bindings”

 Fill the bindings details as bellow and click “Bind”

 As a Routing Key use

The Routing Key will tell what messages will be sent from the Exchange to the Queue.
In this case this queue will receive only messages about VMs successfully created.
if you need to act based on other events, confirm the notification message format.

That’s it, RabbitMQ is ready to start receiving message notification from vCloud Director about the successfully creation of VMs.

In the next post I will show you how to configure VMware vCloud to send messages to RabbitMQ.

See you next week.

Monday, October 21, 2013

VMware vCloud Director and vSphere Metrocluster

vSphere Metrocluster or as sometimes knows as Stretched Cluster is a vSphere architecture design that decreases recovery time when disaster/downtime avoidance is a key requirement.
It’s based on the concept that you have your computer resources split between sites and some storage replication between them (to keep the data up-to-date).
To avoid some extra network and storage traffic over the link between the sites, VMware recommends the creation of some site affinity rules, defining a preferably site for each VM, that way the VM will be running just within the hosts of it’s preferable site, exception are made during disasters, on these cases the VMs will be restarted on any available host, no matter what site it’s in.

When you have VM’s creation control, you create the VM you choose what’s preferable site and assign it to the affinity group, so far so good.

Now with the dissemination of cloud environments, automation and self service, the virtualization team does not have the VM’s creation control anymore, they are being created anytime by several people/departments or even other organizations .

Let’s through vCloud Director into the Mix, DRS affinity groups is something vCenter related, your clients are creating VM’s through vCloud Portal, which abstracts vCenter concepts and details, they don’t even have access to vCenter, so vCloud is not aware of vCenter DRS affinity groups !!!!

How do you keep your Metrocluster environment running as it was designed to be ?

VMware’s answer for integrations between applications that do not, natively, communicate with each other is vCenter Orchestrator.
If you don’t know about it yet, VMware has a good Orchestrator’s blog, check it out!!

The idea behind this solution is that VM’s creation from vCloud can be intercepted analyzed and assigned to DRS affinity groups automatically,

Might a diagram helps to understand better how it works

1.     Through vCloud Portal, the client provisions a new vApp/VM;
2.     vCloud Director requests the VM’s provisioning to VMware vCenter;
3.     vCloud Director publishes the new VM information to the messaging queue;
4.     vCenter Orchestrator consumes the message;
5.     vCenter Orchestrator identify the VM and choose which group it should belongs to;
6.     vCenter Orchestrator sends a requisition to vCenter to change the DRS affinity group membership;
7.     vCenter add the new VM to the defined affinity group.

WOW how cool is that ?!?

On the next posts I will show you the details about how to implement a solution like that:

Stay tuned.

Friday, October 11, 2013

vCNS Manager Step by Step

VMwarevCloud Network and Security (vCNS), also used to be called vShield, provides network and network services for virtual environments like VMware vSphere and VMware vCloud Director.
vCNS leverages routing services through  vCNS Edge, which also provides firewalling, NAT, VPN, DHCP, VXLAN, You can also implement an agentless antivirus solution with vCNS Endpoint, all of that in a matter of minutes.
But the management of all these services are handle by a single component, vCNS Manager.
I know there is a lot of information about how to implement it out there, but for my own records and why not help others, I’d like to create my own step by step procedure on how to install vCNS Manager.

First download the appliance from VMware Web site
Yes you heard it right!! It’s a virtual appliance, easy to implement, I bet you are already enjoying it ; )

From vSphere Client start the process of deploying the appliance
- Select the OVF file you just downloaded and click Next

- Review the details and click Next

- Accept the EULA and click Next
- Give it a name and select the Datacenter where to deploy it. Click Next

- Select the Cluster where to deploy it and click Next
- Select the Resource Pool where to deploy it and click Next
- Select the Datastore where to store the vCNS Manager disks and click Next
- Select the Disk Format and click Next
Thin disk is perfectly OK for vCNS Manager.

- Select the correct Port Group for the appliance and click Next

- Review the Information and click Finish

The deploy will just starts up and a progress bar will be shown

Once deployed we need to configure it.

Throug vSphere Client open vCNS Manager console.
Login in with User: Admin and password: default
Run enable command to enter into a privileged session
Run setup to start the configuration script
- fill with your network information
allow at least few minutes before attempting to configure it. So the appliance can starts all it’s services .

Once Configure you can access it through your WebBrowser. ( https://”vCNS-Manager" )
- Login again with the above credentials to finish the configuration

Let’s starting changing this default password
- Click on the Change Password link

Type a new password and click OK.

At the main page, you have the option to configure several parameters, while some of them are not required, I strongly advise to configure them all.
- Click on the Edit button to starting configuring each one of them

Obviously vCenter Server is the critical one.
- Click on Edit and then fill the information about your vCenter server and a credential with Administrator privileges on it. Click OK.

- Just click Yes on the certificate warning

Now we just need to license the product.
- On the Licenses page select vCloud Network and Security, right click on it and select change license key.

- Just pick up the right license and click OK

That’s all folks !!!  
Easy, right ?!?!  You are now ready to start creating your own virtual network services.

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions. Reach me at @dumeirell

Most Viewed Posts

Blog Archive