Keep Your Existing Operational Process on Oracle Cloud VMware
Operations teams often struggle to handle the diversity of the enterprise IT landscape. Adding public cloud and Kubernetes has expanded the range of infrastructure and applications that require operational support. The last thing operations teams need is something familiar that they must manage as something new, yet that is how most vSphere on cloud products work. We found that the Oracle Cloud VMware Service (OCVS) is the most enterprise-friendly of the products that we looked at during our project with the CTO Advisor team. It is no accident, the team that built the OCVS platform, and the Oracle Cloud Infrastructure (OCI), in general, want to be friendly to enterprise IT teams. The OCVS cluster that we deployed integrated with our existing vSphere environment as if it were simply another data center. After the initial deployment, all of the operational tasks took place in the usual vSphere and NSX consoles, where we had full administrative access.
Full Access to vCenter
The vCenter server is all yours; you get full administrative access to the vCentre inventory, as well as to the VAMI interface where you maintain the vCenter server. If you set up routing back to your on-premises vCenter, then you can set up linked mode between the on-premises and OCVS based vSphere clusters. With linked mode, you get one inventory view with your on-premises clusters and your OCVS clusters visible. Management of your OCVS based cluster is exactly the same as the management of your existing clusters. You can even choose when you upgrade the OCVS vCenter server and use whatever vSphere version you need to match your upgrade of on-premises vCenter.
Full Access to ESXi
The ESXi hosts are all yours too. You can log in directly to the web interface on the ESXi hosts, and you even have a root equivalent login for SSH access. The only difference we noticed is that Oracle has implemented the best practice of using pre-shared RSA keys, rather than a root account password that is the same for every ESXi host. We were able to log on to the ESXi hosts and run commands; in an upcoming video, we will demonstrate vSphere HA by intentionally crashing an ESXi host using a console command. If you need to, you could install custom drivers or support tools that are distributed as VIBs. Organizations that have used vSphere for a long time may have support processes or products that favor using custom packages and ESXi commands, even though these techniques are not used in more modern tools. You also get to control ESXi patching and updates, using standard vSphere tools or any third-party tools and scripts you may choose.
Full access to NSX
The NSX network is all yours; you can log in to the NSX console and configure the subnets and routing that you require. The Oracle cloud network is simply an underlay; your VMs all live on NSX based portgroups. We used the same network connection and routes from on-premises for vSphere management and VM access. Inside the Oracle network, there is an SDN router. We defined routes for the NSX subnet range that were direct to the VTEPs on the NSX edge. The networking behaves just like networking on-premises, maybe a little better because the underlay is software-defined.
The Cluster is yours
The central theme here is that the vSphere cluster that you deploy on the Oracle Cloud VMware Solution is all yours. Oracle provides automated deployment, but you have full control, just like with your on-premises vSphere. The result is a minimal variation from the processes you already use to manage your existing vSphere clusters. For infrastructure operations teams that already manage a fleet of vSphere hosts, the OCVS will simply be another cluster. You can apply the operational and management processes and tools you already use to OCVS with minimal changes.
