As promised, I am posting the recording for the 5th Session of vROps Webinar Series 2016. Both Sunny and I successfully delivered the session on Design and Deployment considerations.

Session Details:- In this instalment of the series, we discussed the steps and thought processes that should be used before and during the design and deployment of vRealize Operations Manager. During the session among other things we will cover the planning, core components, correct sizing, HA, clustering, DR and future growth**.**

Time to announce the next part of the year long webinar series on vRealize Operations Manager. This time around, Sunny  and I thought about discussing Architecture of vROps. To some, it might sound strange as for smaller deployments you might not have to worry about Sizing and Architecture much since it is pretty simple to install and configure a small or a medium node for a small shop. However as your monitoring needs grow and you start adding solutions for monitoring data sources beyond vSphere, you would need to think about scaling up or scaling out. As your monitoring environment weaves into your incident ticketing system, you would start to see the need to HA of vROps and as you have a DR strategy for your workloads, you will start thinking about DR for your operations tools as well.

I ran into this problem at a customer site where all the Log Insight nodes were changed due to some IP address conflicts. I think the problem occurred because the IP addresses were all changed and the VMs shut down, without time for the application to update the node IPs.

The symptoms:

• The web interface was down, a netstat -ano | grep -i “443” showed the service was listening
• _service loginsight status|restart|stop|start _hung and then timed out on the Master node
• The loginsight service was not running on the Worker nodes
• /var/log/loginsight/runtime.log contains warning messages about “Cassandra cluster not ready yet”

• Running /usr/lib/loginsight/application/lib/apache-cassandra-*/bin/nodetool status showed the two data nodes down (DN) and used the old IP address

All of the nodes were up with their new IP addresses, however Cassandra on the Master node was still looking for the old IP addresses for the Worker nodes. The Worker nodes were in a similar state, knowing their own new IP addresses but not being able to update the Master node because they didn’t have the Master node’s new IP address.

If you have used vCOps (previous version of vROPs) you will likely remember the option in the admin panel where you could change the number of metrics being collected from “balanced” to “full”.

As many found, this option drop down was not present in vROps and there appeared to be no replacement.

Here is the good news, the ability to collect those metrics has not been removed rather it’s just a little more hidden (by design)

As promised, I am posting the recording for the 4th Session of vROps Webinar Series 2016. We successfully delivered the session on Contention Based Performance & Capacity Management using vRealize Operations Manager!

        <p>
          <b><i>Session Details:- </i></b>With this instalment of the series, we have a new speaker <a href="https://twitter.com/e1_ang">Iwan Rahabok</a>, who will entertain and educate us 🙂 He is no stranger to the world of vRealize Operations Manager and has written a couple of books on vROps as well.
        </p>
        
        <p>
          During this session we will help you understand a few basic concepts of using the right counters to monitor performance and capacity in your infrastructure. We will deep dive into the concept of the consumer and the provider layer and help you with solving issues which you might face as a provider of infrastructure to your business.
        </p>
        
        <p>
          <b>I also want to personally thank <a href="https://twitter.com/Sunny_Dua" target="_blank">Sunny</a> & <a href="https://twitter.com/e1_ang">Iwan</a><a href="https://twitter.com/simoneady"> </a>for their continued support to this series.</b>
        </p>
        
        <p>
          <b>Here is the recording for this session:::</b>
        </p>
        
        <p>
          Note : It is recommended that you watch the video in HD quality for a great experience.
        </p>
        
        <p>
          <iframe width="500" height="281" src="https://www.youtube.com/embed/mhXkiRWXEBg?feature=oembed" frameborder="0" allowfullscreen></iframe>
        </p>
      </div>
    </div>
  </div>
</div>

Recently I was asked to develop some vRealize Orchestrator workflows against the F5 BIG-IP iControl REST API, but I was not able to test freely against a production appliance. After a lot of attempts to get in contact with F5 for a 90-day trial of the full version, or to purchase a lab license, I came up empty handed. The free version you can download from F5’s website is version 11.3, which does not feature the iControl REST API, which was released in 11.4.

Big thanks to Jose Luis Gomez for this solution, his response to my tweet was spot on and invaluable!

I’ve been trying to configure vCloud Air as a vCloud Director host in vRealize Orchestrator in order to create some custom resource actions for Day 2 operations in vRealize Automation. What I found was that there’s *very* little information out there on how to do this, and I ended up writing my own custom resource mapping for the virtual machines to VCAC:VirtualMachine objects - at least that way I could add my resource action. But this still didn’t expose the vCloud Director functionality for those machines. To do this I needed vCloud Air added as a vCloud Director host.

So a lot of noise is being made about vROps being able to scale out and rightly so it works -very- well.

However what if you want to scale up your node or nodes, going from say small to medium?

Reasons why?

• Perhaps your POC has proved so useful you want to move it into production?
• You have lots of really useful historical on your existing smaller build and you don’t want to redeploy (therefore losing your historical data)
• You have limitations where scaling out is simply not an option but you need vROps to take on more work.

There are likely other compelling reasons for you to want to scale up your vROps nodes so lets look at how we can do that.

We hope you are having fun with the vROps Webinar Series and learning in the process!

With the next instalment of this series, we have a new speaker who will entertain us 🙂 He is no stranger to the world of vRealize Operations Manager and has written a couple of books on vROps as well. I am referring to Iwan Rahabok who has been my partner in crime on all the vROps related work which we do, inside VMware or with the community.

I think this is the first time I have written a “rant” post (for a while at least) so if you don’t want to hear me whine run away now!

In the past 12 months I think I have met more folk with Architect in their job title than I truly believe is valid. Now I will be clear this is not a slight on the individuals all of them have been exceptional (at least the ones I have had the pleasure to work with).