Virtualization on Oracle SPARC T7-2 - our test results
The main goal of testing the Oracle SPARC T7-2 server was to get acquainted with new technologies for hardware acceleration of the Oracle DBMS using the new Oracle M7 processor, on the basis of which the server is built (more about this in our next articles). In parallel, we tested the virtualization functions of the Oracle VM for SPARC hypervisor on the server, which will be discussed below.
Servers of the Oracle SPARC T-series line are positioned as Enterprise-level machines for consolidating multiple systems on a single physical server. To do this, they have the built-in Oracle VM for SPARC hypervisor, the advanced capabilities of the Solaris 11 OS for supporting virtual environments, as well as a multi-core multi-threaded architecture. Previous models in the line - Oracle T4 / T5 servers - are used for similar tasks. Customers often use the T4 / T5-series servers as a replacement for several legacy SPARC servers. That is why Oracle SPARC T7-2 primarily interested us in terms of virtualization capabilities.
There are no fundamental differences in terms of virtualization between the T7 and T5 lines. The same Oracle VM for SPARC hypervisor is used, but a more recent version. Architecturally, the T7-2 server allows more flexible distribution of its I / O resources between individual virtual machines (Logical domain, LDom) due to the appearance of dedicated I / O controllers (previously they were directly integrated 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 operational. One of the most significant nuances is that older versions of the OS will have to be abandoned: T7-2 imposes certain restrictions on the versions of the Solaris OS 10 and 11 used.
Fig. 1. General configuration of the Oracle SPARC T7-2 server 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 necessary OS version, pre-installed software packages, user environments, etc. Once you create such a template, you can deploy similar virtual machines to 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 a large number of small environments and systems to a virtual environment 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 the virtual machine, which physically belongs to one of the control domains (for example, the primary domain). Thus, all those devices that are connected to this physical adapter are directly accessible inside the virtual machine. 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 a number of limitations. The main one is that devices, Connected to the physical adapter, they will be available to all guest domains that are assigned the corresponding “virtual HBA”. This can create problems with resource isolation between different guest domains. Nevertheless, 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 functionality is developing. We hope that this restriction will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. This can create problems with resource isolation between different guest domains. Nevertheless, 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 functionality is developing. We hope that this restriction will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. This can create problems with resource isolation between different guest domains. Nevertheless, 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 functionality is developing. We hope that this restriction will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. That this restriction will be somehow eliminated in future firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. That this restriction will be somehow eliminated in future firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back 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 settings management tools for 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 can be executed only by means of the command line. To date, 2 options are available for graphical management of OVM for SPARC virtualization tools. We designated them as “light” and “heavy”. The easy option is 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 built-in database, while the server hypervisor itself does not actually know anything about virtual machines. If the OVM Manager server fails or this database is damaged, the domain configuration will be lost. In addition, a number of operations on the initial server setup (creating primary / secondary domains, sharing physical resources) using OVM Manager is impossible in principle, you will need to do it by hand. In general, the use of OVM Manager is 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,
Fig. 2. Oracle VM Manager Architecture Oracle
Enterprise Manager Ops Center offers a different approach. At its core, Ops Center is a comprehensive converged solution for managing the entire IT infrastructure, including servers, OS, 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 makes full use of 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 those companies that need complex, non-standard virtual machine configurations. Note that the extensive functionality of Ops Center is partly its drawback: the product is quite “loose”, its study requires a certain amount of time and perseverance. Nevertheless, the solution allows you to reduce the presentation of the entire IT infrastructure of the company in one console.
Fig. 3. Oracle Enterprise Manager Ops Center Architecture
Conclusion from the results of our testing: Oracle SPARC T7-2 server is well suited for consolidation and virtualization of environments operating on the SPARC platform. Using this equipment, the tasks of building distributed virtualization farms with dynamic redistribution of resources and ensuring high reliability can be very effectively solved. The consistent development of virtualization tools improves platform stability, functionality, and usability for end users. The availability of automated controls also simplifies day-to-day operation tasks and improves the return on use. Given the new performance features built into the CPU (Oracle Database In-Memory), the server seems to be a very profitable investment in IT infrastructure.
The article was prepared by Yuri Semenyukov, Head of Corporate Solutions, Center for Designing Computing Complexes, Jet Infosystems. We welcome your constructive comments.
Servers of the Oracle SPARC T-series line are positioned as Enterprise-level machines for consolidating multiple systems on a single physical server. To do this, they have the built-in Oracle VM for SPARC hypervisor, the advanced capabilities of the Solaris 11 OS for supporting virtual environments, as well as a multi-core multi-threaded architecture. Previous models in the line - Oracle T4 / T5 servers - are used for similar tasks. Customers often use the T4 / T5-series servers as a replacement for several legacy SPARC servers. That is why Oracle SPARC T7-2 primarily interested us in terms of virtualization capabilities.
There are no fundamental differences in terms of virtualization between the T7 and T5 lines. The same Oracle VM for SPARC hypervisor is used, but a more recent version. Architecturally, the T7-2 server allows more flexible distribution of its I / O resources between individual virtual machines (Logical domain, LDom) due to the appearance of dedicated I / O controllers (previously they were directly integrated 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 operational. One of the most significant nuances is that older versions of the OS will have to be abandoned: T7-2 imposes certain restrictions on the versions of the Solaris OS 10 and 11 used.
Fig. 1. General configuration of the Oracle SPARC T7-2 server 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 necessary OS version, pre-installed software packages, user environments, etc. Once you create such a template, you can deploy similar virtual machines to 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 a large number of small environments and systems to a virtual environment 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 the virtual machine, which physically belongs to one of the control domains (for example, the primary domain). Thus, all those devices that are connected to this physical adapter are directly accessible inside the virtual machine. 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 a number of limitations. The main one is that devices, Connected to the physical adapter, they will be available to all guest domains that are assigned the corresponding “virtual HBA”. This can create problems with resource isolation between different guest domains. Nevertheless, 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 functionality is developing. We hope that this restriction will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. This can create problems with resource isolation between different guest domains. Nevertheless, 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 functionality is developing. We hope that this restriction will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. This can create problems with resource isolation between different guest domains. Nevertheless, 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 functionality is developing. We hope that this restriction will be somehow eliminated in the next firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. That this restriction will be somehow eliminated in future firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back up directly to tape drives. That this restriction will be somehow eliminated in future firmware versions. In general, it makes sense to use the vHBA mechanism in those cases when you need simplicity in configuring disk devices or you need access to specific SCSI devices directly from guest domains. As an example, back 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 settings management tools for 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 can be executed only by means of the command line. To date, 2 options are available for graphical management of OVM for SPARC virtualization tools. We designated them as “light” and “heavy”. The easy option is 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 built-in database, while the server hypervisor itself does not actually know anything about virtual machines. If the OVM Manager server fails or this database is damaged, the domain configuration will be lost. In addition, a number of operations on the initial server setup (creating primary / secondary domains, sharing physical resources) using OVM Manager is impossible in principle, you will need to do it by hand. In general, the use of OVM Manager is 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,
Fig. 2. Oracle VM Manager Architecture Oracle
Enterprise Manager Ops Center offers a different approach. At its core, Ops Center is a comprehensive converged solution for managing the entire IT infrastructure, including servers, OS, 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 makes full use of 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 those companies that need complex, non-standard virtual machine configurations. Note that the extensive functionality of Ops Center is partly its drawback: the product is quite “loose”, its study requires a certain amount of time and perseverance. Nevertheless, the solution allows you to reduce the presentation of the entire IT infrastructure of the company in one console.
Fig. 3. Oracle Enterprise Manager Ops Center Architecture
Conclusion from the results of our testing: Oracle SPARC T7-2 server is well suited for consolidation and virtualization of environments operating on the SPARC platform. Using this equipment, the tasks of building distributed virtualization farms with dynamic redistribution of resources and ensuring high reliability can be very effectively solved. The consistent development of virtualization tools improves platform stability, functionality, and usability for end users. The availability of automated controls also simplifies day-to-day operation tasks and improves the return on use. Given the new performance features built into the CPU (Oracle Database In-Memory), the server seems to be a very profitable investment in IT infrastructure.
The article was prepared by Yuri Semenyukov, Head of Corporate Solutions, Center for Designing Computing Complexes, Jet Infosystems. We welcome your constructive comments.