0

Our current production environment is XP 9.1.1 scaled on Azure App Services PaaS.

We need to quickly provision a new staging environment as an exact replica of current production one.

As you are aware, we have custom code, content, and hotfixes.

What is the fastest way to achieve our objective?

We have incoming campaigns and we need to assure system performance & endurance by applying load test on the replicated environment.

2 Answers 2

0

You have two options:-

#1

  1. Clone your WebApp and create a new one with a new URL.
  2. In your Site group settings, create a new one and set the URL of the new web app and keep the older one as it is.

Run it. Now you have 2 CD instances and 1 CM instance.

#2

If you are using any standard or above plan like S1, S2, S3.. (I believe you have as you are asking for production environment) then you can create a slot and copy all the content over there. Use the URL of your slot and create a new option in Site group settings and access it.

#1 should be recommended. The only advantage of Slots is, you don't need to pay any extra cost.

Please note, for both approaches, you have to deploy the code base separately.

Usually, we upscale the UAT environment like production and do the testing over there. You can also go for that route instead of creating a new instance if it is suitable for you.

4
  • Neither of these suggestions are a good plan considering OP is planning to run load testing on the new environment. Both of these approaches will DOS the production environment. Apr 12 at 13:08
  • This one I believe for UAT env, not prod. Even though, can you please highlight the exact issue on point #1? Happy to learn. :)
    – Arkadeep
    Apr 13 at 5:04
  • The issue is that your new web app will still be connected to the prod db, xconnect and solr. When you run load tests you will max out your DB and Solr, dos’ing your production site. #1 would be ok for an emergency bug fix, but it’s not going to work for load testing. Apr 13 at 8:30
  • If we put the DBs into elastic pools, then I guess this issue will be over.. Keeping a single web DB can handle the situation. but again your point is correct. Should have multiple web dbs and solr slave for different CD web apps.
    – Arkadeep
    Apr 21 at 20:01
0

If you are planning on load testing your CD environment, you will need to copy not only the Azure Web Apps but also the databases and supporting services as well. In a scaled environment this means many databases and depending on your setup 3 or more web apps, plus potentially Solr servers too.

If you did not use ARM Templates or Terraform to setup your environment in the first place, there is no "quick" way to do this, you're going to have to identify the necessary pieces and copy them one at a time.

Start with the databases. Create a new SQL Server elastic pool and simply "restore" your Azure SQL DBs into this pool. You may need to restore the DB first then add it to the pool. You can rename the DBs after restoring from SQL Management Studio.

Copy Solr Services. If you are using a service like SearchStax you might be able to raise a ticket and ask them to clone your existing server. If you are operating Linux VMs in Azure you can snapshot the disk and clone the snapshot into a new VM.

Create a new Azure App Host. DO NOT USE THE EXISTING PROD HOST FOR LOAD TESTING. The purpose of a load test is to find the exhaustion point of a configuration. You WILL (SHOULD) denial-of-service your own website during the test, so you probably don't want to do that to your Production site.

Azure Web Apps can be "cloned" into a new host. This is the easiest way, otherwise you need to:

  1. create new web apps
  2. use the Kudu console or FTP to download all the files from the PROD sites to the new sites (Kudu can be used to upload the files too)
  3. copy the App Settings and Connection Strings from the prod sites' Web App Config to the new sites
  4. Update connection strings to ensure your apps are connected to the Databases you created earlier and the Solr you cloned

If you know exactly what to do, and your databases aren't too big (i.e. under 10GB) you can pull this off in about a day by hand. Properly scripted in about 30 minutes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.