Turbonomic Architecture, Deployment, and Installation
Turbonomic ARM v8.x runs as a containerized platform on Kubernetes. The exam tests whether you can map each microservice to its job, pick the right deployment model, and name the prerequisites that most often break an installation.
Core components
- API / UI: browser traffic is REST to the API; the UI is a separate deployment.
- Auth: local accounts, plus LDAP/AD and SAML.
- Topology Processor: builds and continuously reconciles the supply chain graph.
- Mediation: hosts the probes that collect from targets such as vCenter, AWS, Kubernetes, and storage.
- Market: the economic engine where buyers (workloads) bid for commodities (CPU, memory, IOPS, latency) sold by hosts, datastores, and clouds.
- Action Orchestrator: executes actions or hands them to an external orchestrator.
- PostgreSQL, Kafka, Consul: shared persistence, messaging, and service discovery.
- Reporting: report generation and scheduling.
Deployment models
Three supported patterns: a VMware OVA, an AWS/Azure marketplace image, or a Kubernetes/OpenShift cluster where the Turbonomic operator is installed and a custom resource describes the platform. All of them need static addressing, working DNS, NTP/time sync, and network paths to every target. Sizing is driven by managed workloads (VMs plus containers), not by UI users.
Worked example
A vCenter target shows Validation failed, yet its VMs are still listed. Reasoning: mediation cannot reach vCenter, or the credential lacks read permission; the topology processor keeps the last known graph until fresh data arrives, so stale entities are normal. Check connectivity and the read-only service account, then revalidate. Reinstalling the platform fixes nothing.
Traps
Assuming the market collects data (mediation does); assuming each service owns its own database; sizing for user count instead of workload count.