The following is a list of information regarding Remote Collectors in vRealize Operations Manager 6. Hopefully this helps administrators when determine if and when to use them in their deployment of vRealize Opeartions Manager 6.
Use Cases for vRealize Operations Manager Remote Collectors
- WAN bandwidth – main saving here is likely to come from vCenter traffic direct to analytics cluster vs. via RC: direct to cluster uses SOAP which is a verbose protocol whilst RC uses a more efficient binary protocol that reduces data to approximately 24 bytes per sample per VM. This is approximately 10x smaller than equivalent traffic over SOAP protocol (i.e. direct to cluster). Please note that we have customers who nevertheless have remote sites reporting directly back to the cluster (no RC) with no issues. Some of these sites have ~1000 VMs. Use an RC if bandwidth is likely to be a problem. NB – there is no advantage for vSphere traffic unless there is a local vCenter at the remote site. RC does not do compression as such, the benefit to vCenter traffic comes instead from the difference in protocols. Bandwidth advantage for other management packs is therefore hard to quantify.
- Firewall Rule Simplification – RC always communicates with analytics cluster via 443, 6061 and 10000. This predictable communication can make configuring firewall rules easier. Without an RC it’s possible that a somewhat arbitrary mix of ports must be allowed between the remote site and the analytics cluster. E.g. the Brocade MP uses 3 ports which are configurable, the NetApp MP uses a configurable port, the SCOM MP uses a configurable port, the HDS MP uses 3 configurable ports. Depending on the mix of local devices to monitor and any custom configuration of the ports, there may be multiple arbitrary ports to accommodate at a single site and, potentially, a different set of ports at another site even assuming same set of devices. Use an RC if this is likely to be an issue.
- Security – all traffic is encrypted by default.
- Processing offload – Using an RC isolates data collection from data processing. This can result in a beneficial reduction is processing overhead for a loaded analytics cluster. A very large adapter instance that doesn’t work well on the internal collector because there is not enough memory/cpu/etc. You can create a separate RC and it will be able to use more of the memory for the collection services allowing my adapter to work. This also isolates data collection from the data processing.
- Hosting MPs which require Windows – When the central analytics cluster is Linux-based (either vApp or installable) an MP which requires Windows to work can be installed on a Windows-based RC. NB whilst VMware supports heterogenous RCs for this use case, the nodes in the analytic cluster (master, master replica (if applicable) and any data nodes) must all be of the same type. vApp, Linux (installable) and Windows (installable) are all supported for the analytics cluster but they must be all of one type.
The behavior in 6.0 is that the Collector and Suite API on the Remote Collector make GemFire calls directly to any member of the GemFire cluster using proprietary GemFire ports and protocol. They first connect to the GemFire Locator which directs them to one of the nodes in the GemFire Cluster. They then send their GemFire request to that node in the cluster.
The SCOM adapter allows vROps to pull data from the the SCOM database. SCOM does not push data to vROps. Additionally, you will need a Windows based Remote Collector or Windows Based vROps Data Node to allow connections to the SCOM database as Microsoft will only support Windows Authentication to the SCOM database as mix mode is NOT supported. Windows Authentication can only be achieved via a Windows based Remote Collector or Windows based vROps Data Node.
New in vROps 6.1 – See Release Notes for additional info
Remote collector resiliency
New functionality enables you to assign solutions to collector groups. Collector groups provide high availability access to data collection for the solution. Use collector groups to achieve adapter resiliency where the collector experiences network interruption or becomes unavailable.
See Managing Collector Groups for additional information.
Q & A
- Does a remote collector take up a seat in the 8 node cluster limit or is this external to the 8 node limit?
- No, a remote collector is not part of the server side of the cluster.
- What is the relationship of a remote collector to a remote vCenter? Can one remote collector be configured to support many remote vCenters or only one?
- A remote collector can run any number of adapter instances (vCenter servers, NSX, Etc)
- Remote collectors only gather objects for the inventory, without storing data or performing analysis. In addition, remote collector nodes may be installed on a different operating system than the rest of the cluster nodes.
- The main part of the cluster that does not include remote collector nodes is informally referred to as the analytics cluster.
- On RC Redundancy. We have not concentrated on having hot backups of the RC because it is (Supposed to be) a stateless object. This means that for disaster recovery you can deploy a new RC with the same name and it will take over the work of the previous RC. That being said there are some adapters that need information within the RC that make it not stateless today. AWS for example needs specific keys in the global java registry. So, while we handled most of the certificate use cases, the AWS API requires the certificate to be in the java truststore and not in a custom truststore. That being said, most adapters (vCenter, Remediation for sure) will work fine in this case.
Update: January 19, 2016 with additional collector group information.
Update: April 13, 2016 with Microsoft SCOM Management Pack Info.