Showing posts with label VMware. Show all posts
Showing posts with label VMware. Show all posts

Wednesday, May 9, 2018

First book - VMware NSX Cookbook

I haven't been blogging lately because I was writing a book on VMware NSX. It all started in early February 2017 when someone from Packt Acquisition Editor reached out to me and informed me that they were looking for someone who can author a cookbook on NSX. I wasn't sure as I haven't authored a book and English is not my first language so I don't think I would be the best person at that time.

After reading up on Packt cookbook format; apparently, a cookbook is focused more on 'How to do it' and 'How it works'. Reading few cookbook examples, I can see that most of the cookbooks are not heavy on the theory. I would just need a small intro section and then the focus would shift to 'How to do it'. I've been designing and deploying NSX for the past few years so I think I should be able to take this opportunity to contribute more to the community through authoring a book.

But still I wasn't too sure if I should take this opportunity, so I reached out to Iwan Rahabok to gather further insights about authoring a book as he has authored multiple books with Packt. He mentioned that writing a book is damn painful and luckily he wrote few tips for the first-time author here: http://virtual-red-dot.info/tips-first-time-book-author/. I still think that I could do with more help, to ensure I write a good quality cookbook and Packt is open to the idea of co-authors. I asked around in the VMware NSX communities and thanks to Dale Coghlan, he introduced me to one of his colleague in the VMware NSBU - Tony Sangha who is keen to author a book on NSX and my first impression was that we would be a great team!

After teaming up with Tony, the next step is for us to create an outline for all chapters, what would be covered in each of the chapters, how many recipes, how many pages and when we can deliver each of the chapters which are not easy as we don't know how many pages it would be after writing and this is our first time authoring a book! Once all the final outline had been agreed with the publisher, we then needed to sign the contract and start the chapter writing - we started to write our first chapters in April 2017.

After many sleepless nights, we were finally able to jointly release the book and become published authors in late March 2018. Thanks to everyone involved, huge thanks to Dmitri Kalintsev for the technical review and Sjors Robroek for the foreword. The book is now available on Packt and Amazon as per the following li


If you are interested to review the book, I might be able to get an eBook copy from the publisher. Feel free to reach me on twitter/email for more information or for any feedback you have!

Wednesday, April 16, 2014

VMware vCenter SQL Database Maintenance Best Practices

People often ask on what are best practices on maintaining vCenter SQL Database.
One of the VMware Best Practices (listed in VMware Health Check/HealthAnalyzer tool) is to periodically perform database maintenance tasks on the vCenter database.
When vCenter server service is stopped and cannot be started, most of the problem is because the disk which stores the DB data is full.
This is why monitoring the disk space and utilization is important to ensure that the database has sufficient space for growth.
We also should schedule regular backups of the vCenter database. The backup for vCenter Server should also include the SSL certificates and licenses from the vCenter Server.

vCenter stores configuration, tasks, events and performance data records in Database, the configuration record usually do not grow or changing most of the time, only happens when we change the setting of a cluster, adding host to cluster, etc. Tasks, events, and performance data records do grow over time and will populate table rows in Database as time goes by.

vCenter Server has a Database Retention Policy setting that allows you to specify when vCenter Server tasks and events should be deleted. vCenter has mechanism to purge the database so that it does not overgrow. There is some built-in vCenter SQL DB automated jobs in Microsoft SQL Server to clean performance data, tasks and events records in Database. Since the retention policy does not affect performance data records, it is still possible to purge or shrink old records from the database using the scripts available in this KB
Reducing the size of the vCenter Server database when the rollup scripts take a long time to run
http://kb.vmware.com/kb/1025914

To access the Database Retention Policy setting in the vSphere Client: Click Administration > vCenter Server Settings > Database Retention Policy.
If it's not set, then it means there is no imitation on how long vCenter will keep tasks and events records in the database, this can also lead to database overgrowth. The default setting is 180 days, so vCenter will purge old data after 180 days.

vCenter performs basic statistics operations of insert, roll up, and purge. Higher statistics levels require that more work be performed by the vCenter Server for these operations, which can impact the performance of the vCenter Server database.
Higher statistics levels also increase the size of the vCenter database. You can use the database sizing estimator when changing the statistics level to make sure that you have adequate space in the vCenter database.

vCenter statistics levels:
  1. vCenter statistics level 1 includes the basic metrics but does not include statistics for devices.
  2. vCenter statistics level 2 includes all the metrics including statistics for devices.
  3. vCenter statistics level 3 includes all the metrics and all of the counter groups.
  4. vCenter statistics level 4 includes all the metrics supported by vCenter Server.
To prevent performance data from growing so large, we can set the stats collection level to 1.
It is recommended that the vCenter statistics level is kept at level 1 or 2. Level 2 gives more comprehensive vCenter statistics than the default setting.
When increasing level statistics from default level 1, monitor closely the vCenter database growth.

Consider upgrading to vCenter 5.1+ if you are still using vCenter version prior v5.1.
vCenter Server 5.1 introduces some significant improvements to the statistics subsystem. The improvements are especially important for vCenter Server 5.1 deployments running at-scale inventory. The database is therefore a critical component of vCenter Server performance. Because the statistics data consumes a large fraction of the database, proper functioning of statistics is an important consideration for the overall database performance. Thus, statistics collection and processing are key components for vCenter Server performance.

VMware vCenter Server 5.1 Database Performance Improvements and Best Practices for Large-Scale Environments: https://www.vmware.com/files/pdf/techpaper/VMware-vCenter-DBPerfBestPractices.pdf

Below are some references & KBs related to vCenter Database Maintenance: