SAP HANA is the preferred database for all future SAP applications. Columnar databases and the in memory capabilities of SAP HANA make it an excellent platform for all SAP applications. Virtualized SAP HANA (SAP HANA) provides significant advantages over Physical HANA implementations by providing flexibility and agility in operating a HANA environment
SAP HANA environments have a large memory footprint with the majority of data in memory. The changes to the memory are constantly being replicated to disk and there can be significant disk activity on the system in spurts. In addition when the system is restarted or there is any high availability event there is a massive requirement for data that needs to be quickly loaded into memory from disk. Due to these reasons, there is a requirement in HANA to have a highly performant IO subsystem. All Flash Storage can be a great asset if used as shared storage for virtualized HANA implementations as they can provide excellent IO performance. This paper looks at the benefits of using virtualization that is backed by All Flash storage for SAP HANA.
Microsoft Exchange Server is one of the mission critical applications most commonly virtualized on the vSphere platform. As customers become more comfortable and familiar with virtualization in general and the VMware vSphere virtualization platform in particular, they become more confident, enough to virtualize their Exchange Server environments. To help customers achieve success as they begin to virtualize their Microsoft Exchange Server infrastructure, VMware provides guidance and recommendations for designing, configuring and managing the infrastructure.
The Microsoft_Exchange_Server_2016_on_VMware_vSphere_Best_Practices_Guide contains VMware’s official prescriptive guidance and recommended practices for successfully running Microsoft Exchange Server on the VMware vSphere platform.
Some administrative practices, like a bad habit, have more lives than the proverbial cat – they tend to stay around forever. It is, therefore, very comforting when one finds a problematic administrative practice that has not just been universally abandoned by administrators, but is also on the top of any junior administrator’s “configurations sure to get you dis-invited from the next user group meetup” list.
Take the case of the old practice of synchronizing a virtual machine’s clock with its host’s clock in a vSphere environment. That used to be “the thing to do” way back when. It was actually the default configuration option on the ESX platform in those days. Until everyone got wiser and the message went out to every admin far and wide that such configurations was no longer kosher. Even VMware got religious and stopped making that option the default behavior. Continue reading