And finally, this is the latest part of the VCF 50 Concepts series, but not the end! Because way more is coming.

If you missed any of the first 3 Posts, it is better to first look at Parts I, II, and III.

Let's get started!

Token ID: Each SDDC Manager Workflow is based on several tasks and subtasks. Every Task has its Token ID. When it comes to troubleshooting, it is critical to identify the Token ID of the failed subtask because it will make it easier to find the source of the problem on the proper log files.
You can find the Token ID in the Tasks view in the UI of the SDDC Manager, expanding the workflow task and identifying the failed subtask.

opID: This is the Operation ID for an entire Task. You can find the opID associated with one particular Task in the Logs, and the Token ID (Subtask) will have an associated opID for the main Task.

SOS Tool: The SOS Tool is a group of command line tools included in the SDDC Manager. You need to ssh to the SDDC Manager virtual appliance using the vcf user. Once you're connected, you enter the following command: sudo /opt/vmware/sddc-support/sos < - - option-name>

VCF Support Bundle: Thanks to the SDDC Manager SOS Tool (via SSH), it is possible to create a súper bundle Log that includes all the critical Logs you want to upload to your VMware Support ticket.
When using the SOS Tool, you have to select a Workload Domain and components like vCenter, ESXi, NSX Manager or more to include into a single file. This is an extremely useful feature to make troubleshooting even simpler.

API Explorer: Like any modern application, SDDC Manager has their API, which makes VCF even more efficient, being able to automate several tasks. Depending on the VCF version, some tasks must be run only via API.
The API Explorer is an embedded API Client in the SDDC Manager UI, and it is very useful because it's extremely easy to use; apart from that, it includes a series of examples and JSON validation that make our lives easier.

OSA: Stands for Original Storage Architecture, and this is the historical vSAN Architecture. OSA is available in all VCF versions and the easiest way to recognize that vSAN Infrastructure is because it's based on Disk Groups or 2-tier Storage composed of Cache and Capacity.

ESA: Stands for Express Storage Architecture, and starting on vSphere 8 and VCF v5.1, it is the new and modern vSAN Storage Architecture based only on NvME Disks using only 1 Tier named Storage Pool.
vSAN ESA comes full of improvements and plenty of efficiencies.

HCI Mesh: Allows sharing a vSAN Datastore to be mounted as a Remote vSAN Datastore in the "Client" Cluster. An HCI Mesh can be configured as a Principal Storage on a VI Workload Domain using Compute-Only Hosts.
HCI Mesh, in VCF, is not supported on Stretched Clusters, but the Remote vSAN Clusters can be configured as a Secondary Storage in any Cluster from any Workload Domain.

AZ: Availability Zone is the name received in VCF to the equivalent of Data Site in vSAN Stretched Cluster. It defines a physical site with at least 4 ESXi hosts that will work with a Domain in Stretched Mode (with vSAN Stretched enabled). VCF requires a minimum of 4 Hosts per Data Site, and before you Stretch any VI Workload Domain, the Management Domain must be Stretched first.

VCF Stretched Cluster - vLans detailed

Witness Site: Apart from the AZs, in a VCF-stretched scenario, it is required to have a Witness Site independent from any Availability Zone. In the Witness Site, the Witness Virtual Appliance will be deployed.
The virtual machine of the Witness Appliance must work on top of an ESXi Host, so it is not supported using any platform like AWS EC2 or Azure VM instances.

Witness Host: This Virtual Appliance works as a quorum or tie-breaker on Stretch architectures. The requirements for the Witness Host in VCF are the same ones as in vSAN, outside the VCF. If you deploy an ESXi Host in a third site to host the Witness, that ESXi will be associated with the Management Domain, not the vSAN Stretched Cluster.

Remote Clusters: It is possible to deploy a VI Workload Domain with vSphere Clusters backed from 3 up to 16 ESXi Hosts that will be located on a Remote Site. The requirements for connectivity are 10Mbps bandwidth and 100 ms of Latency, and one VI Workload Domain will have Local or Remote Clusters but not both. The vCenter instance will work in the Management Domain, as usual.

Image provided by VMware by Broadcom

Multiple or Diverse SSO Domains: Since VCF 5.0, it is now possible to create a new and independent SSO Domain when we create a VI Workload Domain. In older VCF versions, we worked, by default, with only one SSO Domain for all the Workload Domains in VCF (Management and VIs). This feature is especially useful in Cloud Director scenarios because it helps us to isolate the environments working with a more real multi-tenant mode.

Dirty Host: After we remove a Host from a vSphere Cluster, whatever the reason, that Host will appear in the SDDC Manager as an unassociated Host, but it will not be available to be used in the creation of a new Cluster or to expand an existing Cluster. The Host will show a "Cleaning needed" message in the inventory, and the best way to solve that is first to decommission the Host, redeploy the ESXi hypervisor and commission the Host again.

Cloud Inventory: When working with multiple VCF instances, in the VMware Cloud Console, you can see in the Cloud Inventory the details of connected VCF instances and their resources like the number of Clusters, Hosts, Cores, VMs plus CPU, Memory and Storage resources.
The Cloud Inventory replaced the old and depreciated VCF Multi-Site Federation for multi-instance management.

Cloud Foundation Deployment Specialist: This is not a concept; it's an exam, but I highly recommend you prepare yourself for this one and go for it. It is challenging but not rocket science and will open plenty of doors full of opportunities. Attendance of the official course is not mandatory, but you have to hold a current version of the VCP-DCV certification.

And that's it! We're done with the 50 VCF Concepts but stay tuned because, in the next post, we will cover some VCF Design recommendations and Tips for the Deployment.

This Post is Part III in the VCF 50 Concept series. If you missed Part I and Part II, I recommend you look for a better understanding first.
In Part III, we are going to focus on the Lifecycle.

Let's get started!

VCF Lifecycle Management: This is one of the most exciting features of Cloud Foundation. Integrated into the SDDC Manager and comparable with the Vienna Symphonic Orchestra, the Lifecycle Management orchestrates the upgrade of the entire solution in combination with vSphere Lifecycle, NSX and Aria Suite Lifecycle.

Online Depot: Public VMware Repository where the SDDC Manager can download the available Patch and Upgrades.
Suppose the SDDC Manager is not allowed to connect to the Internet. In that case, it is possible to manually download the files and move them securely from a laptop to the SDDC Manager using the Bundle Transfer Utility.

Backup Server: This is a storage repository for the SDDC Manager file-based backups. The SDDC Manager provides the same storage to the NSX Manager Cluster to make it possible to configure the file-based backups of the NSX. Configuring the Backup Server in VCF is a MUST, mainly because it will be the only Backup for the NSX Clusters.

TIP: For my VCF deployments, I use one virtual machine as a backup server repository for the SDDC Manager and the NSX Manager Clusters and the file-based backup of every single vCenter Server. The storage depends on the amount of VI Workload Domains you plan to deploy, and one AlmaLinux or Ubuntu works fine.

Note: Remember to schedule the script to remove the Old NSX Backups to avoid storage capacity problems in your backup repository.
https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-ECFFBD6D-4D2F-4773-B552-B27D4ECE0AC4.html

Aria Suite Lifecycle: This is the new name of the solution since VCF v5.1 (formerly vRealize Suite Lifecycle Manager), and it provides the Lifecycle for the "VCF optional components" that belong to Aria Suite like Aria Automation, Aria Operations, Aria Operations for Logs and more.
The "Suite" word indicates that Aria Lifecycle is deployed in "VCF Mode" using the SDDC Manager.
To be ready to deploy the Aria Suite Lifecycle from the SDDC Manager, you have to previously deploy an EDGE Cluster and an AVN in the Management Domain.

AVN: Stands for Application Virtual Network and it's a group of virtual elements like two network segments, one NSX T1 and one NSX T0, that provides the required infrastructure for deploying the Aria Suite Lifecycle. The AVN will be deployed only on the Management Domain, and the requirement is to previously deploy an NSX EDGE in the same Management Domain using the SDDC Manager.

Password Management: Another great feature the SDDC Manager provides is that it allows us to centralize the management of the ESXi's, vCenter, NSX Managers and Aria Suite Lifecycle.
With this feature embedded in the SDDC Manager, it is possible to rotate all the passwords, schedule the password rotation, or simply manually set a new password for one particular account.
You can manage this using the UI or, even better, using the SDDC Manager API!

Note: After a password rotation, remember to export the list of the new passwords. You can do that using the lookup_passwords via the SDDC Manager command line or the API.

Certificate Management: The SDDC Manager allows us to create CSR (Certificate Signing Request) and Install/Replace the certificates of the SDDC Manager, vCenter Servers, NSX Managers and Aria Suite Lifecycle using the UI or the API of the SDDC Managers.
It is possible to integrate a Microsoft CA with the SDDC Manager, use Open SSL embedded in the SDDC Manager or work with a 3rd party CA.

Identity Sources: Once the Bring-up is finished, the SDDC Manager uses the vCenter Server of the Management Domain SSO as the Identity Provider. It is possible to integrate, from the SDDC Manager, an Active Directory or an OpenLDAP to the vCenter Server SSO.
The SDDC Manager has only three types of Roles: Admin, Operator and Viewer.
Since VCF version 5.0, it is possible to isolate the SSO of any VI Workload Domain or, if preferred, you can share the same SSO with all the vCenter Servers and, for instance, you will work with enhanced linked mode between all the vCenter Servers.

Security Tip: Consider using an AD different from the company's for the management infrastructure for security reasons. That isolation won't guarantee security, but at least you won't depend on the security and risk of the Corporate AD using an air gap identity manager only for the Operations team.

Solutions (vSphere with Tanzu): This is an option in the main SDDC Manager menu and is where the SDDC Manager runs a validation for the Domain and Cluster where we want to deploy vSphere with Tanzu.
The validation includes the number of hosts, principal storage, license, and EDGE cluster.
At some point, the names are a nightmare because they start with Solutions, and after the validation, the wizard continues in vSphere Client, where the menu name is Workload Management, and it has nothing to do with VCF. (Is it complex enough? Enjoy it!)

Workflows: Every task run on the SDDC Manager works with a Workflow in the background. There are several workflows, and those workflows are the heart of VCF.
When it comes to VCF troubleshooting, it's good to know that every workflow will have an associated Token ID, which will be extremely useful in case of a failure when you have to look at the Logs.

All right! In this way, we've reached 33 VCF Concepts!

In the next Post, we will focus on Stretched Cluster, vSAN in general and EDGE Clusters. Stay tuned!

This second post of the 50 VCF Concepts blog will cover the main concepts related to the general Infrastructure and the VI Workload Domain creation.

If you missed Part I of the series, I recommend you start there first.

Let's get started!

VCF Deployment: There are two types of Cloud Foundation Deployments. Those two Deployments are Single Site and Stretched.
It is also possible to describe a VCF Deployment using the term "VCF instance", especially when the VCF Deployment has finished.

VCF Architecture: There are two Architectures or ways to Deploy a Cloud Foundation: Consolidated and Standard.
The VCF Deployment can work without any VI Workload Domain (Consolidated) or (Standard) up to 14 VI Workload Domains.
Starting with a Consolidated Deployment will allow you to migrate from a Consolidated to a Standard Architecture.

Image provided by VMware - VCF Design Guide

Region: Logical concept used to identify and group the components of a VCF Deployment. One Region equals one VCF Deployment, and it is possible to have a VCF Single Site or Stretched Deployment under the same Region.

Single Site Deployment: The Deployment of one VCF instance under one Region and on top of one physical Datacenter.

Stretched Deployment: The Deployment of one VCF instance under one Region using two AZ (Availability Zones) for Compute and Storage plus a Witness Site. The Stretched Deployment will help to increase the Availability using vSAN Stretched Cluster.

Availability Zone: Physical Datacenter or placement (like a building) with independent and redundant power supply, networking, compute and Storage. There is no rule for the distance between two AZs, but there are several requirements regarding networking to support a Stretched VCF Deployment such as no more than 5 ms round trip between AZ1 and AZ2.

(Old Concept, not valid since new subscription only mode) VCF+: Subscription offering of Cloud Foundation. It enables access to VMware Cloud Console to view multiple VCF instances.
When working with the subscription method, you won't use the perpetual licenses in the SDDC Manager.

(Old Concept, now "Disconnected mode" available) Cloud Gateway: You can see VMware Cloud Gateway or vCenter Cloud Gateway names for the same thing, and it is an on-prem virtual appliance that will provide the information needed to manage the subscription for VCF+ between your SDDC Manager and VMware Cloud Console.
When working with VCF+, you must manually deploy the Cloud Gateway on top of the vSphere Cluster in the Management Domain.

Network Pool: Network segment definitions for vMotion and, optionally, vSAN, NFS and iSCSI where you must define, per service level, the vLan ID, MTU, Network, Subnet Mask, Gateway and one or more IP Range.
The SDDC Manager will use these parameters for the network service configuration while deployment or scaling workflows work.

Best Practice: Use one Network Pool per vSphere Cluster. This way, you'll isolate the vMotion and, potentially, vSAN and NFS network segments per Cluster level.

VCF Network Pool creation

Host Commissioning: Procedure that takes place in the SDDC Manager via UI or API, where you will add the ESXi Hosts to the inventory of the SDDC Manager. Once you have enough unused Hosts in the inventory of the SDDC Manager, you will be able to extend an existing vSphere Cluster, create a new vSphere Cluster in an existing VI Workload Domain or create a new VI Workload Domain.
The ESXi Hosts that will be part of the same Cluster must share the same Network Pool and Principal Storage.

Note: The recommendation is to use homogeneous hardware per Cluster level, considering network and storage devices.

VCF Host Commissioning

Host inventory: The SDDC Manager holds a Host Inventory where you can see two types of Host states: Unnasigned and Assigned Hosts.
After you remove a Host from a Cluster, you must "clean" that Host before you can use it again.

Lifecycle Update Management method: Every time you create a VI Workload Domain, you must select the Lifecycle Update Management method that defines if you will use the legacy option based on Baselines (will be depreciated) or the choice based on Images.
You need to know that every single vSphere Cluster belonging to that VI Workload Domain will share the same Lifecycle Update Management method.

Note: depending on the VCF version, you can find a limit or requirement for the Update Management option.
For example, if you will Stretch a VI Workload Domain or need to deploy vSphere with Tanzu, then you must select Baseline as the Update Management method, and once you choose that option, you won't be able to change it.

Principal Storage: Every vSphere Cluster must have defined its Principal Storage. The available Principal Storage types are vSAN, NFS, vVOLs and VMFS. Depending on the Storage type, the SDDC Manager will automate the storage configuration while creating the vSphere Cluster.
All the ESXi Hosts of the vSphere Cluster must work with the same Principal Storage.
If you want to work with vSAN in that new vSphere Cluster, you must define vSAN as Principal Storage.

Supplemental Storage: Once the SDDC Manager creates the vSphere Cluster, you can "manually" configure additional Storage outside the SDDC Manager (using vCenter Server). This second Storage, called Supplemental Storage, can be NFS, VMFS or vVOL.

Note: If any of the Principal or Supplemental Storage options must use ethernet services (vmkernel port groups) to connect to the Storage server, you must define that service (NFS or iSCSI) in the Network Pool.

And finally, a simple MinMap to take a look at these concepts.

Part III is ready!

When it comes to VMware (now Broadcom) Cloud Foundation, there are a series of concepts that we need to consider a "must" if we pretend to understand the whole solution.
In this Post, we will cover 50 VCF Concepts to understand the solution globally, including relationships, tips and best practices.

Let's get started!

First release: Dec 4th 2023 (the first ten concepts)

VCF: Stands for VMware Cloud Foundation. This virtualization platform is based on vSphere for Compute, vSAN for Storage and NSX for Networking and Security. VCF is based on the Software Defined Datacenter concept and provides the entire solution's lifecycle management. Cloud Foundation is also based on what we know as the "VMware Reference Architecture", following the best practices.
There are different versions like 4.5, 5.0, and 5.1, and some editions will include more or less functionalities and services.
Nowadays, VCF is "THE" virtualization solution based on SDDC for Private, Hybrid and Public Datacenters for Virtual Machines and Modern Applications.

BOM: Stands for Bill of Materials, and every VCF version is based on a particular BOM that defines the specific version of every component like the ESXi, vCenter Server, SDDC Manager, NSX Manager and more.
That list of versions was defined based on the matrix interoperability, providing an already validated compatibility in terms of interoperability.
You can check the VCF BOM in the Release Notes of every product version.

Cloud Builder: a virtual appliance that will run the bring-up to automate the initial deployment of the basic components of VCF, like the first vCenter Center with a 4-node vSAN Cluster, SDDC Manager and the NSX Manager Cluster. Those components are the basement of the Management Domain.
The virtual appliance won't be deployed in any of those 4 ESXi hosts that will be used for the Management Domain, so we can use any other host or just a Laptop. The Cloud Builder virtual machine will be deleted after the bring-up process is finished.
The size of the Cloud Builder OVA file is pretty heavy because it includes not just the Cloud Builder but the vCenter, SDDC Manager, and NSX Manager deployment files.

Bring-up: is the workflow that runs on top of the Cloud Builder virtual appliance for the initial deployment of VCF.
This workflow will need the "Deployment parameters", which is an Excel file or it can also be in JSON file format and defines the collection of parameters needed like the FQDN of the ESXi hosts, DNS servers, NTP, VLANs, passwords and more.
Depending on the hardware resources, the amount of time that the bring-up needs to deploy the Management Domain is about 2-3 hours.

Planning and Preparation Workbook: It's an Excel file that can be considered a masterpiece. Since the first meeting, we'll start defining a lot (I mean it) of things like sizing, hardware, network segments, resource distribution, uplinks, security and more. A lot more.
The Planning and Preparation file is a marvellous file that we will use for the proper collection of parameters needed for the whole project, like the amount of VI Workload Domains, the passwords, VLANs, FQDNs, NTP and a considerable amount of parameters.
This file will be used for the entire project and not just for the Management Domain.
You can download the Planning and Preparation Excel file from the product documentation page, and it must match the exact version of the VCF that will be deployed.

Deployment Parameters: Excel or JSON file that defines all the required parameters needed to run the bring-up. This file will be attached to the Cloud Builder wizard and, first, will be used for the initial validation, and then, if validation succeeds, will be used during the bring-up.
All the required parameters can be obtained (manually) from the Planning and Preparation, and the file can be downloaded from my.vmware.com or during the Cloud Builder wizard.
Again, it's a must to use the exact same Deployment Parameters version as the VCF version that will be deployed.

Domain: VCF resources are logically grouped based on Domains.
A VCF deployment will have one and only one Management Domain. Based on the design, the VCF instance can have from 1 up to 14 VI Workload Domains. It is even possible to work with what is called a Consolidated Architecture, which uses only a Management Domain.

Management Domain: The Management Domain is originally based on four ESXi hosts working on a DRS, HA and vSAN Cluster. The bring-up will deploy five virtual machines in the Management Domain. Those virtual machines are the SDDC Manager, vCenter Server (for Management) and three NSX Managers.
Depending on the VCF design, it will be possible to deploy an NSX EDGE Cluster for Management.
When a VI Workload is created, the vCenter Server virtual machine will be deployed in the Management Domain Cluster. If that new VI Workload Domain will be deployed with their own NSX Cluster, then the three NSX Manager virtual machines will be deployed in the Management Cluster.

VI Workload Domain: VI stands for Virtual Infrastructure. Any workload that is not part of the Management will be deployed on top of a vSphere Cluster that belongs to one VI Workload Domain.
There are different use cases for the deployment of the VI Workload Domains: Production Critical, Production non-critical, QA, Tanzu, VDI and more.

Note: Do not be confused with the Workload Management. Workload Management is the name used in the inventory of the vSphere Client where you will deploy or manage the Supervisor Cluster (Tanzu).
You will see a Workload Management in the SDDC Management, but that will be only for pre-deploy vSphere with Tanzu validation purposes.

SDDC Manager: Virtual appliance that provides the HTMLv5 UI for the Management of the VCF that also includes an API and a command line resource.
The SDDC Manager includes a series of embedded workflows for the lifecycle of all the components in Cloud Foundation.
It is easy to say the SDDC Manager is for VCF the same as vCenter is for vSphere.

And these were the first 10 VCF concepts! Did you like it? Can you help me to share it?

Looking forward to hearing your feedback.

Next step -> Cloud Foundation 50 Concepts - Part II

Otro gran Podcast en el que junto con mi compi Héctor (@nheobug) nos visita el gran David 8 bits (@ochobitsunbyte) en el que lo ametrallamos a preguntas sobre automatización. 

El Crack de David nos cuenta cómo es trabajar con Puppet, el sistema de Gestión de la Configuración más utilizado, y cuáles son los principales casos de uso así como también su combinación con otras herramientas como Ansible y Terraform.

Agradecemos enormemente a David por regalarnos su tiempo y compartir su sabiduría.

Episodio de lujo en Un Podcast para TI en el que con mi compi Héctor Herrero (@nheobug) recibimos al gran Eduardo Collado (@ecollado), grandísimo profesional que lo sabe todo sobre el área de Networking.
Con Eduardo mantuvimos una muy amena charla en la que nos contó las piezas clave de un Datacenter haciendo especial énfasis en la parte de la electrónica de red que se encarga del Networking de Capa 2 y Capa 3.

Muchas gracias Eduardo por regalarnos tu tiempo y compartir tus conocimientos.

Seguimos con mi compi Héctor Herrero (@nheobug) entrevistando gente increíble en el Podcast, en esta ocasión nos visita nuevamente el gran Ousman Umar (@ousmanumar) de la ONG Nasco Feeding Minds y CEO de Nascotech.

Ousman nos cuenta la evolución de su ONG y cómo, a través de la tecnología, es capaz de ayudar a miles de niños en Ghana (su país natal) para aportar su granito de arena y ser capaz de crearles oportunidades, sobre todo a través de Nascotech, para evitar que pongan en riesgo sus vidas y sufran lo que el mismo Ousman pasó en su travesía hacia Europa.

Sin dudas merece la pena dedicar unos minutos de nuestra vida para darnos cuenta, a través de estas historias, de que con tan poco podemos hacer mucho para ayudar a los demás.