| Unique Visitors |
I think you misunderstand virtualization. At least when it comes to virtualization of business critical apps. When virtualizing business critical apps performance and SLA's matter way more than consolidation or cost savings. It is about improving on SLA's. Also HANA relies on having persistent storage to save checkpoints and recover points for the in-memory data. This is so it can be recovered in the case of a system outage. You can effectively stripe data across multiple HANA instances for reliability and recovery also. But when you add virtualiztation you gain manageability and reliability features you wouldn't otherwise have if the system was running bare metal native configuration on the hardware, such as vMotion, such as HA. HA allows you to get back to 100% operational state much quicker than if you didn't have it. vMotion allows for non-disruptive updates and maintenance of physical servers. The additional integration with tools such as LVM, when it supports HANA, will allow for complete automation and creation and tear down, or resizing of landscapes, without having to do manual operations. The difference in performance tests between traditional queries of a BW workload taking 77 minutes is 14 seconds on HANA, and 14.91 seconds when HANA is virtualized. Would you really make a decision to not virtualize and miss out on the benefits (manageability, flexibility, reliability and availability) of that for 0.91 seconds of additional performance? How long does it take to stand up a pure physical HANA instance? A few weeks, as you have to order new hardware etc. How long does it take to stand up a new vHANA instance? A few minutes. Applications and dev/test teams can be far more productive when their systems are virtualized, including production systems. Virtualizing business critical applications is about not compromising and designing the system from the ground up to meet the requirements, including performance, and not compromising SLA's, while gaining all of the benefits of virtualization. Some cost savings are probable, but that is not the main driver, and that is a nice to have. If you're trying to virtualize critical apps only for cost savings then you're doing it wrong, and you'll likely cut corners that will end up costing you far more than any potential savings would have.
]]>Virtualizing HANA actually increases the benefits. If you virtualize it on vSphere you get near native performance while still being able to take advantage of high availability, vMotion for non-disruptive server maintenance and the ability to create new instances very quickly and on demand. You get all the benefits of HANA and all the benefits of virtualization.
]]>Thanks, I hadn't noticed that. Although you can use HANA in a VMware backed cloud and for small instances I doubt it would be one instance per server. This space will evolve rapidly and I expect we'll see scale out designs supported before too long also.
]]>in production environments, just 1 SAP HANA VM per physical ESXi host is supported, see http://www.vmware.com/files/pdf/SAP_HANA_on_vMwar…
bye
mmaz