Oracle SPARC T7-2 Virtualization - Our Test Results
The main goal of testing the Oracle SPARC T7-2 server was acquaintance with new technologies for hardware acceleration of the operation of the Oracle DBMS using the new Oracle M7 processor, on the basis of which the server is built (see our next articles). In parallel, we tested the Oracle VM for SPARC hypervisor virtualization functions on the server, which will be discussed below.
Oracle SPARC T-series servers are positioned as Enterprise-level machines for consolidating multiple systems on a single physical server. To do this, they have an embedded Oracle VM for SPARC hypervisor, advanced Solaris 11 OS support for virtual environments, as well as a multi-core multi-threaded architecture. Previous line models — Oracle T4 / T5 servers — are used for similar tasks. Customers quite often use T4 / T5-series servers as a replacement for several outdated SPARC servers. That is why Oracle SPARC T7-2 primarily interested us in terms of opportunities for virtualization.
There are no fundamental differences in terms of virtualization between the T7 and T5 lines. It uses the same Oracle VM for SPARC hypervisor, but a more recent version. Architecturally, the T7-2 server allows you to more flexibly distribute your I / O resources between individual virtual machines (Logical domain, LDom) due to the advent of dedicated I / O controllers (they were previously integrated directly into the CPU). However, in essence, the general approach to setting up a virtual environment remains the same, and the existing functionality is relevant and fully functional. One of the most significant nuances is that you will have to give up obsolete OS versions: T7-2 imposes certain restrictions on the versions used by the Solaris 10 and 11 OS.
Fig. 1. The overall configuration of the Oracle SPARC T7-2 virtual environment as part of our tests
')
During testing, we also tested new features that appeared in the latest versions of the hypervisor. One of them is OVM templates (the so-called “templates” for quickly creating virtual machines). You can create your own templates or use existing ones. The template includes virtual machine settings (LDom), the required OS version, preinstalled software packages, user environments, etc. Once you have created such a template, you can deploy similar virtual machines on other servers much faster and more efficiently than creating them from scratch. This feature can greatly facilitate the task of deploying a large number of similar virtual machines. This may be relevant for those administrators who need to transfer to the virtual environment a large number of small environments and systems in a short time.
Another innovation is virtual HBA (vHBA) technology. This mechanism allows you to fully emulate a full-fledged SCSI adapter (FC HBA) on a virtual machine, which physically belongs to one of the control domains (for example, the primary domain). Thus, within the virtual machine, all those devices that are connected to this physical adapter are directly accessible. Those. disk devices, tape drives, etc. can be directly assigned to a specific guest domain. Previously, such functionality was absent - disk devices were “forwarded” to the domain through the creation of virtual disk client - virtual disk server pairs, tape drives could not be presented to the guest domain in principle. It should be noted that the mechanism currently has several limitations. The main one is that the devices connected to the physical adapter will be available to all guest domains that are assigned the appropriate “virtual HBA”. This can create problems with resource isolation between different guest domains. However, the presence of such a function is another step towards simplifying the configuration of the virtual environment on T-series servers. I am glad that the functional develops. We hope that this limitation will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from the guest domains. As an example, backing up directly to tape drives.
During testing we paid special attention to the functionality of automated server management and its virtualization environment. First of all, I was interested in the availability of graphical controls for setting up the OVM for SPARC hypervisor. This task may be of interest to customers who widely use Oracle SPARC virtualization and who want to reduce the amount of "manual" procedures that are executed only by command-line tools. At present, 2 options are available for graphical management of OVM for SPARC virtualization tools. We designated them for ourselves as “light” and “heavy”. The “easy” option is the Oracle VM Manager software. "Heavy" - Oracle Enterprise Manager Ops Center. Both tools allow you to configure virtual machines on the server from the graphical console. But at the same time, these products have a fundamentally different management paradigm.
Oracle VM Manager software was originally developed as a management console for Oracle VM for x86, SPARC functionality was added later. OVM Manager stores the entire configuration in its embedded database, while the server hypervisor itself does not actually know anything about the virtual machines. In case of failure of the OVM Manager server or damage to this database, the domain configuration will be lost. In addition, a number of operations on the initial setup of the server (creation of primary / secondary domains, separation of physical resources) using OVM Manager is impossible in principle, you will need to perform them by hand. In general, the use of OVM Manager is fully justified for those companies that need to build solutions like “private cloud on SPARC”, i.e. where a large number of light environments and applications are required, while resiliency is provided at the service level, not the hypervisor.
Fig. 2. Oracle VM Manager Architecture
Oracle Enterprise Manager Ops Center software offers a different approach. At its core, Ops Center is a comprehensive converged solution for managing the entire IT infrastructure, including servers, operating systems, networks, storage systems, cluster configurations, DBMS, etc. It has a much wider list of supported hardware and software than OVM Manager. Virtualization management is only a small part of it.
Ops Center entirely uses the configuration from the OVM hypervisor when creating and managing virtual machines. The number of manual operations is actually reduced to zero. Thus, this solution can be used by companies that need sophisticated, non-standard virtual machine configurations. Note that the vastness of the functionality of Ops Center is partly its disadvantage: the product is quite “spreading”, its study requires a certain time and perseverance. Nevertheless, the solution allows to reduce the representation of the entire IT infrastructure of the company in one console.
Fig. 3. Oracle Enterprise Manager Ops Center Architecture
The conclusion of our testing: the Oracle SPARC T7-2 server is well suited to consolidate and virtualize environments running on the SPARC platform. With the use of this equipment, tasks of building distributed virtualization farms with dynamic redistribution of resources and ensuring high reliability can be solved very effectively. The consistent development of virtualization tools improves platform stability, functionality and usability for end users. The availability of automated controls also simplifies everyday maintenance tasks and improves the return on use. Given the new features in terms of performance built into the CPU (Oracle Database In-Memory), the server is a very profitable investment in IT infrastructure.
The article was prepared by Yuri Semenyukov, head of corporate solutions at the Center for Computing Systems Design, Jet Infosystems. We welcome your constructive comments.
Oracle SPARC T-series servers are positioned as Enterprise-level machines for consolidating multiple systems on a single physical server. To do this, they have an embedded Oracle VM for SPARC hypervisor, advanced Solaris 11 OS support for virtual environments, as well as a multi-core multi-threaded architecture. Previous line models — Oracle T4 / T5 servers — are used for similar tasks. Customers quite often use T4 / T5-series servers as a replacement for several outdated SPARC servers. That is why Oracle SPARC T7-2 primarily interested us in terms of opportunities for virtualization.
There are no fundamental differences in terms of virtualization between the T7 and T5 lines. It uses the same Oracle VM for SPARC hypervisor, but a more recent version. Architecturally, the T7-2 server allows you to more flexibly distribute your I / O resources between individual virtual machines (Logical domain, LDom) due to the advent of dedicated I / O controllers (they were previously integrated directly into the CPU). However, in essence, the general approach to setting up a virtual environment remains the same, and the existing functionality is relevant and fully functional. One of the most significant nuances is that you will have to give up obsolete OS versions: T7-2 imposes certain restrictions on the versions used by the Solaris 10 and 11 OS.
Fig. 1. The overall configuration of the Oracle SPARC T7-2 virtual environment as part of our tests
')
During testing, we also tested new features that appeared in the latest versions of the hypervisor. One of them is OVM templates (the so-called “templates” for quickly creating virtual machines). You can create your own templates or use existing ones. The template includes virtual machine settings (LDom), the required OS version, preinstalled software packages, user environments, etc. Once you have created such a template, you can deploy similar virtual machines on other servers much faster and more efficiently than creating them from scratch. This feature can greatly facilitate the task of deploying a large number of similar virtual machines. This may be relevant for those administrators who need to transfer to the virtual environment a large number of small environments and systems in a short time.
Another innovation is virtual HBA (vHBA) technology. This mechanism allows you to fully emulate a full-fledged SCSI adapter (FC HBA) on a virtual machine, which physically belongs to one of the control domains (for example, the primary domain). Thus, within the virtual machine, all those devices that are connected to this physical adapter are directly accessible. Those. disk devices, tape drives, etc. can be directly assigned to a specific guest domain. Previously, such functionality was absent - disk devices were “forwarded” to the domain through the creation of virtual disk client - virtual disk server pairs, tape drives could not be presented to the guest domain in principle. It should be noted that the mechanism currently has several limitations. The main one is that the devices connected to the physical adapter will be available to all guest domains that are assigned the appropriate “virtual HBA”. This can create problems with resource isolation between different guest domains. However, the presence of such a function is another step towards simplifying the configuration of the virtual environment on T-series servers. I am glad that the functional develops. We hope that this limitation will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from the guest domains. As an example, backing up directly to tape drives.
During testing we paid special attention to the functionality of automated server management and its virtualization environment. First of all, I was interested in the availability of graphical controls for setting up the OVM for SPARC hypervisor. This task may be of interest to customers who widely use Oracle SPARC virtualization and who want to reduce the amount of "manual" procedures that are executed only by command-line tools. At present, 2 options are available for graphical management of OVM for SPARC virtualization tools. We designated them for ourselves as “light” and “heavy”. The “easy” option is the Oracle VM Manager software. "Heavy" - Oracle Enterprise Manager Ops Center. Both tools allow you to configure virtual machines on the server from the graphical console. But at the same time, these products have a fundamentally different management paradigm.
Oracle VM Manager software was originally developed as a management console for Oracle VM for x86, SPARC functionality was added later. OVM Manager stores the entire configuration in its embedded database, while the server hypervisor itself does not actually know anything about the virtual machines. In case of failure of the OVM Manager server or damage to this database, the domain configuration will be lost. In addition, a number of operations on the initial setup of the server (creation of primary / secondary domains, separation of physical resources) using OVM Manager is impossible in principle, you will need to perform them by hand. In general, the use of OVM Manager is fully justified for those companies that need to build solutions like “private cloud on SPARC”, i.e. where a large number of light environments and applications are required, while resiliency is provided at the service level, not the hypervisor.
Fig. 2. Oracle VM Manager Architecture
Oracle Enterprise Manager Ops Center software offers a different approach. At its core, Ops Center is a comprehensive converged solution for managing the entire IT infrastructure, including servers, operating systems, networks, storage systems, cluster configurations, DBMS, etc. It has a much wider list of supported hardware and software than OVM Manager. Virtualization management is only a small part of it.
Ops Center entirely uses the configuration from the OVM hypervisor when creating and managing virtual machines. The number of manual operations is actually reduced to zero. Thus, this solution can be used by companies that need sophisticated, non-standard virtual machine configurations. Note that the vastness of the functionality of Ops Center is partly its disadvantage: the product is quite “spreading”, its study requires a certain time and perseverance. Nevertheless, the solution allows to reduce the representation of the entire IT infrastructure of the company in one console.
Fig. 3. Oracle Enterprise Manager Ops Center Architecture
The conclusion of our testing: the Oracle SPARC T7-2 server is well suited to consolidate and virtualize environments running on the SPARC platform. With the use of this equipment, tasks of building distributed virtualization farms with dynamic redistribution of resources and ensuring high reliability can be solved very effectively. The consistent development of virtualization tools improves platform stability, functionality and usability for end users. The availability of automated controls also simplifies everyday maintenance tasks and improves the return on use. Given the new features in terms of performance built into the CPU (Oracle Database In-Memory), the server is a very profitable investment in IT infrastructure.
The article was prepared by Yuri Semenyukov, head of corporate solutions at the Center for Computing Systems Design, Jet Infosystems. We welcome your constructive comments.
Source: https://habr.com/ru/post/311016/
All Articles