Welcome!

Cloud Security Authors: Yeshim Deniz, Pat Romanski, Elizabeth White, Zakia Bouachraoui, Liz McMillan

Related Topics: @DevOpsSummit, @CloudExpo, Cloud Security

@DevOpsSummit: Blog Feed Post

Performance Testing in Production? By @Lounibos | @DevOpsSummit #Cloud #DevOps

Here are 14 grid management best practices you should know

I spent a few days in New York City last week attending a couple of meetups, including speaking at a New York City Web Performance Meetup on Thursday night. I had several great conversations around real user monitoring, data science and analytics, and, of course, testing in production (my favorite topic these days!).

I had quite a few discussions around how SOASTA CloudTest manages these large cloud environments and if there are any best practices for load server grid management, especially when performance testing using a very large, location-diverse — and even cloud provider-diverse — environment.

Well, of course there are! So what better time to write a blog post about grid management best practices when you’ve just spent a few days in one of the best city grids in the world — New York!

Overview of the CloudTest environment
CloudTest’s load server is implemented as a massively multi-threaded service executing all, or parts of, a complex test composition. (Note: A composition can contain many clips.)

A single node can send and validate responses to thousands of HTTP messages per second. Multiple Maestros can be combined to each execute parts of a large load test. Maestros can be geographically distributed and single test compositions can run geographically distributed while still producing a single integrated set of test results and analytics.

That said, once you have created the tests you want to run, CloudTest lets you select and deploy load generators using internal, public and private cloud resources. For example, you can choose resources from Azure, Amazon EC2 or GoGrid cloud services. CloudTest takes care of deploying and provisioning the load generators, benchmarking the virtual servers for their health, and monitoring the CPU of the load generators while they are running. You can literally deploy a test cloud using hundreds of thousands of virtual users around the globe in minutes. And because you are using cloud resources, you pay only for the resources used during the test.

A CloudTest environment typically contains, at a minimum, a “Main Instance” (server) that contains the web application and a “Maestro” service (load generator). For higher-volume situations, there may be a separate database server that contains the Repository and the Results Service with its Result database.

Optionally, there may be additional servers that contain additional Maestros (load generators) and additional Results Services.

This general structure applies, regardless of whether physical servers are being used or a cloud-based environment is being used, or a combination of the two.

In our example in this blog post, let’s target a cloud-based environment for a high-volume situation.

So let’s get started: Best practices for grid management with SOASTA CloudTest!

Load servers are usually automatically managed by CloudTest. The CloudTest user is only expected to deploy and tear down the grid. But there may be corner cases where grid deployment is not successful; in those cases, the grid may not finish deployment or all listed servers may not be functioning properly.

This blog post provides best practices that should be employed to ensure grids are working, as well as provide troubleshooting steps for cases they are not.

Important: Make sure you have all the required servers available before loading a composition.

Launching grids

1. Ensure that the server list is correct before starting, and that there are no servers from previous deployments.
Most often this will not be an issue unless you manually added servers, or a grid has been left up from a previous run. Disabling the servers rather than removing them is sufficient if you wish to retain them in the server list, but typically you’ll remove any old servers.

Grid-Launch.jpeg

In the server list above, there are a number of servers that have been launched as a grid and others that were manually launched and then added to the server list. You can select one or more of the servers and Check Server(s) from the right-click context menu to validate that they are enabled and verified. You may want to leave manually created servers in the server list, even if you’re not using them, so you don’t have to re-add them later. In order to get a valid server list you must uncheck ‘Enabled’ on the ‘Services’ tab for any unused servers.

There are a number of other actions you can take on server, as shown above.

  • Reboot: This may be used if you have a composition that’s not stopping and you want to stop the load but not lose the grid. You would normally have no need to reboot servers.
  • Shutdown: Use this option if the grid has been terminated but there are servers that did not get shutdown or terminated. Tearing down the grid is always the first option and this should only be used if that doesn’t work.
  • Replace: This is the same as shutdown.
  • Delete: This will delete the server from the server list. If the server is no longer running in the Cloud Provider and you simply need to remove it from the server list you would choose delete. Note that deleting a server which is still running in a cloud provider will NOT terminate that server, and will result in an orphaned server running in the cloud.
  • Most of the other commands are for manipulating manually created servers.

2. Under normal circumstances, grid deployment will complete and the green checkmark on the CloudTest UI will be displayed.

Grid-Wizard.jpeg

3. When launching grids, it is best to start with the slowest grids first.
Of the available providers, GoGrid will generally take the longest to launch taking more than 30 minutes in some cases. Azure, Rackspace and HP are all about the same and will take anywhere from about 7-8 minutes to 30 minutes, usually depending on the size of the grid and number of locations. AWS generally launches in 3 or 4 minutes, but could take longer if it’s a grid in the hundreds or thousands of servers.

4. You can launch multiple grids at once, but that is not usually recommended.
When launching multiple grids, you should keep the tabs open for grids that have not finished deploying and should only do so for different providers. You may also see more warnings (such as Server Mismatch) in the server list until all grids have finished deploying if you have multiple grids launching at the same time. While not required, it is easier to troubleshoot (and recover from) issues if you include only a single provider when you launch a grid. You can launch multiple locations for a single provider simultaneously.

5. For GoGrid it’s better to launch multiple smaller grids than one big grid.
For example, if you are launching 36 servers, you can launch a grid of 12 load generators with 1 Result Server and then two additional grids of 12 LGs each. You only need to launch another Result Server if you are going to launch more than 50 load generators in a location. The second and third grids of 12 will find the Result Server that was launched with the first grid. You’ll generally want to keep the grids under 20 servers.

6. If a grid is taking a long time to come up (only one or two servers are left, getting extended timeouts) choose ‘Proceed with X of X’ and supplement with another grid for any additional required servers.
Choosing proceed without stopping allocation will force the grid to begin checking and verifying servers. Again, if you already got a Results Server (or more if you have more than 50 LGs) in that location, you don’t need to add another.

Grid-Monitor.jpeg

Please make sure NOT TO CLICK ‘Stop Deploying’ before clicking the proceed button, you will be prompted after clicking whether or not the grid deployment should be stopped. Also, if you do this you will see the Grid Ready green check but the grid manager progress bars will not fill completely up. You should be able to all of the servers that were deployed prior to clicking the Proceed button. See below for checking servers.

Checking grids

7. Even after receiving green checkmark for grid deployment, it is good practice to run check servers from servers tab on left panel of CloudTest and make sure the status for all servers is OK.

Grid-check-4

Grid-Check-2-July-31

8. If you ‘Stop Deploying’ for any reason in the grid manager, go to Servers tab on left panel of CloudTest and click ‘Check Servers’ for available list of servers.

Grid-stop-deply-July-31

In this particular case, we got 1 Result Server and 5 test servers from Rackspace. There is one invalid test server, which has been automatically disabled by CloudTest.

9. CloudTest also provides an option of manually disabling servers.
This can be done by clicking on the respective server under Servers tab and unchecking Enabled under the Services tab. You can also right-click on a server and reboot or terminate in place. Sometimes, rebooting a server will bring it back to life.

Grid-check-3-july-31

10. Once all the servers are up, it is good practice to run a smoke test with 1 virtual user on each load server in General mode.
This will confirm all servers are sending traffic as expected. You can use the actual test you are about to run by copying the comp and setting it to one user per server, but that is not necessary (and can be difficult if you have a complex composition). The test can be as simple as a single get to any public site or run in preview mode. This will test that all of the servers can be loaded and also that a Result can be created, exercising the Results Service structure (simply loading a Composition does not involve RS, so it does not test the RS infrastructure).

11. Always Load the Composition through the UI first and then press Play, as opposed to just pressing Play.
Loading the composition before pressing play typically allows you to identify and get past any loading errors, which is where bad grid servers may first show up.

Terminating the grids

12. Have the credentials for your cloud providers at hand.
See below. This is only needed if you experience any issues with grids that cause manual intervention as described above.

13. When terminating grids, if CloudTest displays an error the servers can be deleted from the cloud provider dashboard.
This will also require deleting servers in CloudTest under the Servers tab.

14. The servers can also be verified by accessing the console of relevant cloud provider.
So in this case, we are looking at Rackspace console displaying 5 servers in active status and one server still being built.

Grid-last-July-31

Takeaways

When driving load from a cloud-based environment, it is critical to deploy and tear down the grid and to follow the best practices outlined at a high-level in this post. In addition, this should be coupled with SOASTA’s best practices for loading compositions into CloudTest in order to best optimize the load test operations. (Look for that blog post in early August! If you can’t wait until then, join SOASTA’s CloudLink community and search our Knowledge Base for these details.)

Read the original blog entry...

More Stories By SOASTA Blog

The SOASTA platform enables digital business owners to gain unprecedented and continuous performance insights into their real user experience on mobile and web devices in real time and at scale.

IoT & Smart Cities Stories
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...