Server partitioning

from Wikipedia, the free encyclopedia

The server partitioning refers to a logical ( software-based ) or physical ( hardware-based ) separation of a computer system in which one or more autonomous operating system instances and their applications can be operated. Partitioning includes the separation of CPUs, memory, adapter cards and other components, but also ( hosting ) the systems themselves.

instigation

The increasing performance of the hardware suggests combining many (operating) systems with low resource requirements on a few servers. This goes hand in hand with the reduction of space requirements in the data center and the consolidation of numerous repetitive technical components ( power supplies , housings, mainboards , adapter cards, etc.)

approaches

Alternative approaches are in use that implement this idea more or less consistently.

Blade server

No partitioning still in the narrow sense, but are already network and power supplies, storage area network technology in a special chassis housed ( blade servers ) , while the very compactly built remainder server mainly on CPUs , main memory and possibly hard drives are reduced and be inserted into the chassis. The individual blades can be equipped and powerful in different ways. In some cases, different designs can also be combined, usually 10–20 blades per chassis are possible.

Fixed partitions (hardware partitions)

In corresponding computers with multiple system boards, each board can be assigned to a partition. This creates a maximum of as many partitions as there are boards. The partitions can have different capacities. The server can be reconfigured in order to have a different division.

Dynamic partitions (software partitions)

A software layer ( hypervisor ) regulates the access of the partitions to the hardware components. In principle, these can be redistributed during operation. While the addition of components is usually unproblematic, the removal of the affected operating system and the active application software must be coped with, which may require adjustments not only in the operating system but also in the application programs. Operating systems that do not support dynamic partitions can usually still be operated, but the system may only recognize the new configuration after restarting the partition.

Virtual Partitions

The hypervisor simulates virtual CPUs and adapter cards to the operating systems and forwards resource requirements to the physical components at runtime. Thus, several or all partitions share the same physical CPUs and adapters. Individual partitions can be guaranteed minimum CPU resources. CPU resources that are not guaranteed to any partition or that are not used at any one time are made available to any partition very quickly by the hypervisor if required.

Dynamic and virtual partitions are also known as logical partitions ( LPAR ) .

Virtualization

Under virtualization is meant, among other things, a technology that is not installed in an operating system instance directly on a server, but on the hardware via an intermediate layer that abstracts the hardware, or in a host operating system through virtualization software.

The technology with the intermediate layer essentially corresponds to dynamic or virtual partitioning (see hypervisor ). To distinguish it from the software virtualization shown below, the intermediate layer is called the “Type 1 hypervisor”.

With software virtualization, there is a certain logical separation from one another. Duplication or creation as a copy of a master is supported. Disruptions to the overall system due to the resource consumption of a single virtualization cannot be ruled out. Since the virtualization software runs on a host operating system such as Linux or Windows, it is itself relatively hardware-independent, but in return it cannot always make optimal use of the hardware conditions. This type of virtualization software is known as a Type 2 hypervisor.

As with virtual partitions, guest operating systems must be suitable for software virtualization. Special processor commands that should be reserved for the hypervisor or host operating system on virtualized systems can be problematic, because they allow unrestricted access to the entire memory of the machine. Unvirtualized operating systems need this technical means themselves. Therefore, conflicts arise if such an operating system is to subordinate itself to a hypervisor or host operating system, because in principle every guest operating system could now overwrite the memory of another. The problem is usually solved by the guest operating system executing its kernel routines in a less privileged ring (e.g. ring 1). Another question is how all application programs, including possible malicious codes, can be safely kept away from Ring 0.

Another problem is the representation of unique, unchangeable hardware IDs per partition, which may be needed for a license self-check.

Areas of application

Blade servers are comparatively inexpensive and are ideal where a larger number of systems with similar requirements are required. The case that all blades are identical is particularly advantageous because it is simple for the system administrator . Example: web server farm.

Real partitions come into play where more flexibility is required: different and changing size partitions. Partitioned servers are typically large servers with which (also) particularly powerful systems can be operated. The virtual partitions are particularly advantageous because they react particularly flexibly to changing loads and in many applications (e.g. several OLTP partitions) the servers can be designed to be significantly smaller than the sum of the individual requirements.

Software virtualization is particularly suitable when a large number of operating system instances, each with little power hunger, are to be consolidated on a server, and when new instances are to be created and activated quickly. If there are moderate demands on performance and availability, it can also be operated on inexpensive hardware and may require comparatively little additional knowledge.

Partitioning and software licensing models

Software products are often licensed according to the number of CPUs used. This applies, for example, to many database systems, software for data backup, etc. In most cases, a license must be purchased for all CPUs physically present in the machine. Special features of chips with multiple processor cores must be observed: Is one license required per chip (socket) or one per core?

This licensing model is unfavorable if the software is only required on one or a few partitions of a server because more CPUs then have to be licensed than are actually used. A blade server architecture avoids this problem.

There are also license models that take partitioning into account, e. B. "subcapacity licensing", a model that IBM offers for some of its software. The only requirement here is that virtual partitions are limited in their performance ("capped"). Then only licenses are required according to the actually available service.

Partitioning for business-critical applications

The complexity of such a solution is due to certain deteriorations in performance, availability and compatibility with special hardware (adapter, etc.). In addition, the system administrators have a lack of experience in terms of sizing, setting up and operating such architectures. As is usually the case, it is advisable to start small and then, with increasing experience, also approach business-critical processes. In terms of technology, a good level of maturity has been reached, with which business-critical applications can also be run on partitioned servers.