Test drive the clouds: why do you need it and how to do it
So, you have “ripened” to IaaS, studied the market, decided on a cloud service provider and are ready for migration - well, or you think you are ready, but not really. But before we finally cross the Rubicon and go to the cloud, we need to test it properly (oh, my captain, captain). Fortunately, many cloud service providers give customers this opportunity and offer a test drive. Why do you need this "bonus" and how to use it with maximum benefit for yourself - this will be discussed below.
What gives a test drive (and, strictly speaking, a test drive only):
1. First of all, this is the only way to know for sure whether your applications in the cloud will work (not at all, but as it should).
2. At the same time you will be able to identify potential "weak links" and insure yourself for the future.
3. As a result of thoughtful testing, you will also get accurate performance metrics - and the correct numbers for the SLA.
4. This is a good opportunity “on the coast” to study the management tools of a virtual data center, evaluate their convenience and functionality, adapt themselves, etc.
5. The speed of creating and restoring VM backups is another important point that is easily clarified as part of the test drive.
6. And, of course, the quality of the service desk: agree that it is better to check the accuracy of advertising promises before signing the contract, and not after.
Persuaded? Then it's time to figure out what is the right test drive, how to prepare for it and where to look at all.
')
Let's start with the test pool configuration. For each application that is planned to be transferred to the cloud, clearly defined performance requirements are required.
In the case when the service is deployed in the cloud “from scratch”, it is possible to involve an provider to work on the primary sizing.
If we are talking about the migration of applications from hardware, as a starting point, the indicators of the current system are quite suitable:
1. number of users and amount of data
2. loading the main elements of the system, which include:
○ processor
○ memory
○ disk queue
○ network activity
3. The relationship between points one and two.
Well, if there are also monitoring data for some distinct period, then in general beauty. We supplement the metrics of the “normal operation” of the application with a forecast for periods of peak loads - and ship all this to the provider as a statement of work for the test pool of resources. Having gained access to the test cloud stand, we first check whether the key parameters correspond to the TOR: the number of processor cores, speed and volume of the disk subsystem, memory size and width of the network channel.
What exactly will we test? Performance and functionality of the cloud data center.
Performance: what to look at and how to test?
The priority elements of the infrastructure, of course, are determined by the needs of the application for which the cloud “prepares”: if the database is critical for the disk subsystem, then for a number of other software, processor power and memory as a cache are more important.
In this case, there are parameters that are easily changed in the process (memory), but there are those with which it is more difficult: the disk subsystem , the processor and the network . And with these last it is desirable to understand at the start.
How the disk subsystem is checked : here input / output and delay indicators (IOPS, Latency) are important for us, Iometer, SQLIO and FIO can be used for “measurements”.
The processor . When performing load tests, ask the supplier to specify CPU Ready values separately (measured in%): this is the time that the virtual processor spends “in the queue” after the processor time from the physical host. CPU Ready above 10% - a guarantee that the virtual machine will “slow down” as a result of a chronic shortage of processor power.
Network: here we look at the width of the network channel, the stability and response time. It is more convenient to watch through Iperf & Jperf and ping.
We separately check the backup system , namely its functionality, plus the speed of creating and restoring backups.
With the performance figured out. What's next?
Next, we check the functionality and convenience of managing the cloud - that is, we clarify for ourselves how convenient and easy you will be to create and delete virtual machines, distribute resources between them, import and export “virtual machines”, create and store VM templates, manage the network and FireWall, create VPN and monitor consumed resources.
***
If the results of performance testing are not quite, so to speak, reflect - we present them to the provider and together decide how best to “cure” this or that problem. Invented? Be sure to test the updated configuration.
And, of course, having finally achieved the necessary indicators, these figures are included in the SLA (Service Level Agreement) .
That's all I wanted to say. Successful flight!
What gives a test drive (and, strictly speaking, a test drive only):
1. First of all, this is the only way to know for sure whether your applications in the cloud will work (not at all, but as it should).
2. At the same time you will be able to identify potential "weak links" and insure yourself for the future.
3. As a result of thoughtful testing, you will also get accurate performance metrics - and the correct numbers for the SLA.
4. This is a good opportunity “on the coast” to study the management tools of a virtual data center, evaluate their convenience and functionality, adapt themselves, etc.
5. The speed of creating and restoring VM backups is another important point that is easily clarified as part of the test drive.
6. And, of course, the quality of the service desk: agree that it is better to check the accuracy of advertising promises before signing the contract, and not after.
Persuaded? Then it's time to figure out what is the right test drive, how to prepare for it and where to look at all.
')
Let's start with the test pool configuration. For each application that is planned to be transferred to the cloud, clearly defined performance requirements are required.
In the case when the service is deployed in the cloud “from scratch”, it is possible to involve an provider to work on the primary sizing.
If we are talking about the migration of applications from hardware, as a starting point, the indicators of the current system are quite suitable:
1. number of users and amount of data
2. loading the main elements of the system, which include:
○ processor
○ memory
○ disk queue
○ network activity
3. The relationship between points one and two.
Well, if there are also monitoring data for some distinct period, then in general beauty. We supplement the metrics of the “normal operation” of the application with a forecast for periods of peak loads - and ship all this to the provider as a statement of work for the test pool of resources. Having gained access to the test cloud stand, we first check whether the key parameters correspond to the TOR: the number of processor cores, speed and volume of the disk subsystem, memory size and width of the network channel.
What exactly will we test? Performance and functionality of the cloud data center.
Performance: what to look at and how to test?
The priority elements of the infrastructure, of course, are determined by the needs of the application for which the cloud “prepares”: if the database is critical for the disk subsystem, then for a number of other software, processor power and memory as a cache are more important.
In this case, there are parameters that are easily changed in the process (memory), but there are those with which it is more difficult: the disk subsystem , the processor and the network . And with these last it is desirable to understand at the start.
How the disk subsystem is checked : here input / output and delay indicators (IOPS, Latency) are important for us, Iometer, SQLIO and FIO can be used for “measurements”.
The processor . When performing load tests, ask the supplier to specify CPU Ready values separately (measured in%): this is the time that the virtual processor spends “in the queue” after the processor time from the physical host. CPU Ready above 10% - a guarantee that the virtual machine will “slow down” as a result of a chronic shortage of processor power.
Network: here we look at the width of the network channel, the stability and response time. It is more convenient to watch through Iperf & Jperf and ping.
We separately check the backup system , namely its functionality, plus the speed of creating and restoring backups.
With the performance figured out. What's next?
Next, we check the functionality and convenience of managing the cloud - that is, we clarify for ourselves how convenient and easy you will be to create and delete virtual machines, distribute resources between them, import and export “virtual machines”, create and store VM templates, manage the network and FireWall, create VPN and monitor consumed resources.
***
If the results of performance testing are not quite, so to speak, reflect - we present them to the provider and together decide how best to “cure” this or that problem. Invented? Be sure to test the updated configuration.
And, of course, having finally achieved the necessary indicators, these figures are included in the SLA (Service Level Agreement) .
That's all I wanted to say. Successful flight!
Source: https://habr.com/ru/post/196082/
All Articles