Tuesday, February 23, 2016

vRealize Automation Documentation

Along with the release of vRealize Automation 7.0 it also came a slightly change on the documentation location, although small, it seemed to cause some disturb on the force.

On vRA’s documentation page, we were used to have several reference documents, like vRA Reference Architect.

But if you check vRA 7 documentation page, it seems incomplete, someone can further comment those references were not produced for this new version.

Weel, that’s not the case, all the documentation were revised and are publicity available, let’s see how to find them.

-       go to vRA 7 document page;
-       click vRealize Automation 7.0 Information Center 
-       Under: vRealize Automation 7.0 Information / Planning and Resources

There’s it. Now you can find the Reference Architecture
Also if you want to download it, just go under PDF and e-book Documentation

I just used vRA Reference Architecture as an example, but all others references has been moved to this same location.

Have you noticed this change ???

Thursday, February 18, 2016

Big Data Extension – virtual disk options

Today I will write about the virtual disk behavior on vSphere Big Data Extension where it relates to SCSI Controllers and Thin X Thick type of disks.

*** SCSI Controller ***

Every time you create a new BDE node the VM will present, at least, two SCSI Controllers; one for the O.S and swap disks and another one for Data disks.
The O.S SCSI Controller will be the same as what’s already configured on BDE Template, which by default is LSI Logical Parallel

Now, for the Data SCSI Controller, it will always be Paravirtual SCSI Controllers (PVSCSI), which performs better in high I/O situations, like Big Data systems, here’s the Paravirtual performance study case If you want to read more about it.

Starting with BDE 2.3 you can specify controller type of O.S and swap disks:

- Change BDE’s template SCSI disk to Paravirtual and on BDE Server edit:

- Look for the following entry and adjust accordingly:

- Restart tomcat

*** Disk Type ***

There was always discussion about disk performance between Thin and Thick disks, while there’s definitely some performance benefits on Thick Earger zeroed disks, it’s negligible, see the vStorage performance study here for more details.

To start with lest examine the O.S. disk; when you create a new node the O.S disk type will be the same as the BDE Template, which by default it Thick.

TIP: I figured out if you Storage vMotion the BDE template to another datastore and choose to convert the O.S disk to Thin, new nodes will also have O.S Thin disks.

Now about Data Disk; When you configure the Datastores available for BDE consumption will need to configure them as Local or Shared:

- Local mean for disks locally attached to the hosts ESXi;
- Shared mean for external disks managed by storage systems.

So, when you create a new BDE node on a Local datastore the data disks will be Thick.

When you create a new BDE Node on a Shared datastore the data disk will be Thin.

Well, nothing prevents you from setting up Local disks as Shared to have Thin disks on the nodes, be aware that it could cause some vSphere HA issues
BDE might enables vSphere HA on nodes running on Shared disks, but since in reality those disks are local, HA wont be able to restart the VM on another host in case of host’s failure.

See you guys next.

Friday, February 12, 2016

Big Data Extension - Upgrade Clusters Status

In a recent implementation of vSphere Big Data Extension, just after creation of my first Hadoop cluster, I realized I could not manage it, there was a warning message saying: Upgrade the cluster to the latest version.

Almost the same status when I checked through CLI running:
cluster list --name “Cluster” --detail

On my case it was showing Earlier status.
It’s a common situation when you have clusters created on previous versions of BDE, which was not my case; I was on a green field scenario.

Those were the steps I used to troubleshoot it.
- Login on BDE appliance through SSH or console

- run: su serengeti
this would allow you to access the BDE’s database

- run: psql
to interact with postgres

- run: select * from server_info
as you can see, there was no information about my server’s version on the server info table.
To be honest, I don’t know how I end up on this situation, either way if it happens to you, and I hope it does not, it’s how to fix it. 

- run: insert into server_info values(1,true,2.1.0)
make sure you add the version which matches your BDE’s version.

If you run the select command again you will see the table updated accordingly

That’s it, now you can upgrade your clusters and the newer ones wont show this Upgrade message anymore.

BTW, if you right click the cluster and choose Upgrade Cluster or run cluster upgrade command, without making the table changes I show above, the task will finish but the cluster status will still showing you the Upgrade required info.

If you are not confortable on running those commands don’t hesitate to contact VMware Support, they would be glad to help.


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