How to determine the integration rate in the server integration project?

Server integration projects generally start from data collection: Collect server resource requirements and statistical data so that you can determine the server integration rate. In the analysis phase of a server integration project, the goal is to create a complete definition of the final integration status.

The final integration status includes the following:

• A list of servers that will be retained after the server consolidation project. This includes the servers that will be retained and will be purchased.
• The number of virtual machines created on each server. Some servers may not install virtualization software, but are retained as standard servers. These servers host a separate application, a separate database, or a combination of the two.
• The exact location of each application and database instance in this virtual environment. If it is placed in a virtual machine, you need to determine a virtual machine in a specific physical server; if it is placed in a non-virtual standard server, determine a specific standard server.

Which servers should you keep?

In the analysis phase of the server integration project, your first step is to determine which servers will be retained in the new environment. Then you can plan the server consolidation rate. This can be determined by the detailed parameters in the server integration schedule: processor, memory, and network interface.

You may decide to upgrade some servers by adding memory. Once you determine which servers are retained, you can assign simple numbers to them, such as E1, E2, and E3, to facilitate the server integration project's next steps.

Application Integration

Then you can start the main analysis task: Assign each application instance and database instance to a physical server in the final state. If you have hundreds or even thousands of servers in your project, this will be an arduous task. However, some assumptions can help you significantly reduce the number of choices and better plan the server consolidation rate. Of course, a server consolidation project that takes two months to collect data usually does not take three hours to complete the analysis.

When you choose to integrate programs and databases on the same physical server but on different virtual machines, the following are application integration goals:

• Do not deploy more than a reasonable number of virtual machines on a physical server. For example, you may need 10 virtual machines on the production server, but you may need a small number of testing and development instances.
• Virtualization software supports over 200 virtual machines on each server. However, you should avoid deploying such a centralized production instance on a physical server. This causes a single point of failure.
• Do not overload physical servers. Make sure that the total CPU, memory, and network connection resources required by all applications are within the scope of the machine.

To achieve the first two goals, you should mix heavy-load applications with light-load applications or databases on each physical server. Deploying only some light-load applications will not be able to effectively use all the resources of the server, which is contrary to the first article of the Application Integration goal. If you put some heavy-load applications together, you may experience low-performance risks during peak usage of each application.

　Tracking Applications

The Indus IT Valley Application Consolidation lidation Tool, ACT) helps you simplify Application tracing. Other third-party services can also help you plan application integration. If you prefer not to use other tools to complete the recognition process, the traditional method is to extract the information into an Excel table. Each application or database instance in the table can be used as a row. Your application consolidation list should include these columns:

• Application ID/Database ID
• Current server number
• Role
• Green Zone start run date/time and end run date/time)
• Workflow Parameters
• Workflow level
• Special Circumstances
• Physical server allocation
• Number of virtual machines

The first two columns can identify each application or database instance and the current server.

The workflow parameter describes the percentage of resources occupied by the application or database instance on the server that it will eventually be in. Workflow level is a broad classification that you obtain from workflow parameters and some other similar parameters (high, medium, low, not suitable, and so on ).

The special case column should contain key special information about the application or database. This data comes from records in the data center or previous surveys. Before making a final decision on your server integration plan, you need to take into account all the special circumstances of the application.

In the physical server allocation and the number of virtual machines, you will enter a Code such as E3) to identify a group of physical servers that an application or database will be in. The number of virtual machines defines the number of specific virtual machines on this physical server. After you assign all the reserved servers to the final status codes such as E1, E2, and E3, you can assign new servers such as N1, N2, and N3.

To make it easier to determine the physical server in the final state to which each instance is allocated, sort and analyze it based on the preceding application/database instance table. You can take these five steps to implement your server integration plan.

1. Sort applications/database instances that must use a single server in special cases. Enter the code E1, E2, and E3 for each instance at the physical server allocation list ). Fill in "NV" in the list of virtual machines. This will be a non-virtualized server.
2. Sort the remaining instances at the workflow level. Assign a separate server to any instance of the "unsuitable" level.
3. instances that are not assigned to an independent server in the previous two steps are grouped by role and Green Zone. It is a good choice to place instances with the same roles on the physical server. This makes it easier to adopt different standards and support for servers in the future.
4. Assign instances in each group to each physical server in step 3. You should balance the distribution of workflow levels-for example, two "high", three "medium", and five "low ". Determine that the total number of workflow parameters allocated to each physical server is at least 30%, but not more than 50%, relative to the total number of resources on the server. Once your selection looks acceptable, enter the physical server code in the corresponding instance line. And fill in the list of virtual machines from 1, increasing in the same physical server ).
5. Repeat this step until you have allocated all instances in a similar Green Zone. Continue to assign other instances based on the role and Green Zone.