You are viewing limited content. For full access, please sign in.

Question

Question

Migrating On-Prem Servers to Azure - Any Tips?

Migration
Updated December 22, 2023
asked on December 19, 2023

We are going to be migrating our Rio On-Prem system servers to the cloud (Azure) soon.

Our system is spread out between several servers (see attachment) and we are going to be keeping them all separate in the cloud, just as they are on-prem.

The only difference we can think of will that will occur will be related to IP Addresses. Can you think of anything else that might be different?

Are there any changes that I should be making in any of the LF applications to accommodate a seamless migration?

Are there any tips as far as what order (or all at once?) to do the servers in?

 

Any insight is greatly appreciated! 

LF Rio On-Prem Architecture.png
LF Rio On-Prem Architecture.png (99.12 KB)
Download
0 0

Replies

replied on December 19, 2023

Hi Addison,

How are you planning to migrate the servers? Move them as-in with Azure Migrate (or similar) or stand up fresh Azure VMs, re-install applications, and then move the data?

If you can, I'd recommend coming to Advanced SP Office Hours on Tuesday Jan 9, 2024 at 11am Pacific. I'd be happy to talk through the details with you there.

2 0
View 5 previous replies
replied on December 20, 2023

Hi Samuel,

Thanks so much for the response!

All of our current machines are VMs, and we'll be moving them as-is using Azure Migrate (no re-installs needed). We expect it to be pretty easy, the only thing we can think of that will be different will be IP addresses, and we just weren't sure if LF used IP addresses in any sort of way that we'd have to consider.

How do I sign up for the Advanced SP Office Hours on that day?

0 0
replied on December 20, 2023 • Show version history

Advanced SP Office Hours 2024 H1 Registration

We expect it to be pretty easy, the only thing we can think of that will be different will be IP addresses, and we just weren't sure if LF used IP addresses in any sort of way that we'd have to consider.

Only if you hardcoded IP addresses in any of your Laserfiche configurations, for example as an SMTP email server address. If you used hostnames in your configurations (like you should), Laserfiche follows the normal DNS resolution process to look up the IPs.

If you've used hostnames in all your configs, you shouldn't need to anything for Laserfiche other than possibly run "ipconfig /flushdns" in an Administrative Command Prompt / PowerShell session to clear out any cached DNS results from before the migration.

Have you selected what Azure VM sizes you're going to use for each server yet?

0 0
replied on December 20, 2023

Thanks again, Samuel!

The person who initially set up our LF system does not work with us anymore, so I wouldn't know where all to check for IPs being potentially used.

How would I find out where in the system I should check for those?

Most likely, we're going to go with 16vCPU / 32GB memory for the SQL server in Azure. All of the other servers, though, we have not decided on sizing. 

 

Thanks so much for this information, it's really helpful!

0 0
replied on December 20, 2023

Re: the SQL Server, you should review this article:

Checklist: Best practices for SQL Server on Azure VMs

16 vCPU / 32 GB RAM at a 1:2 vCPU:RAM ratio is not ideal. 1:8 is preferred. SQL is memory hungry and unless this system is huge is unlikely to need that much compute power. I'd start with an E8bds_v5 with 8 vCPU, 64 GB RAM, and an ultra-fast local SSD for tempDB files. If you have utilization data showing your current SQL instance actually uses 16 vCPU, you could start with an E16bds_v5 instead. But even in that case, newer/faster hardware in Azure might mean you can get the same performance with fewer cores. In nearly all scenarios, you should use the Ebds_v5 instance family that Microsoft recommends as ideal for most SQL Server workloads.

0 0
replied on December 21, 2023

Our current LF SQL server never goes above 16GB of memory utilization. Based on this, do you think there something on our SQL server that needs to be re-configured?

0 0
replied on December 21, 2023 • Show version history

SQL Server 2016 will use all memory available to it by default. SQL Server 2019 and above have a default of 75% of system memory. That you are seeing it "never go above 16 GB" strongly suggests the "max server memory (MB)" value is set to an artificial cap of 16 GB. Unless the total size of all the databases on the instance is well under 16 GB (highly unlikely), SQL can make good use of more RAM.

See: SQL Server memory configuration options 

Something you should strongly consider is deploying a new SQL Server 2022 on Windows Server 2022 instance using the pre-optimized Azure Marketplace image and migrating your databases to it, rather than moving the old SQL Server itself. The Extended (Security) Support end date for SQL 2016 is July 14, 2026, less than three years away. There are licensing considerations to this (Azure Hybrid Benefit, etc.) so make sure to evaluate that factor.

0 0
replied on December 22, 2023

Thanks, Samuel!

We suspect that the MB is capped, but can't check until our Database guy is back from vacation. We will not be moving to SQL server 2022 at this time, but will be considering sometime in the near future.

We put together a chart showing our on-prem servers and current sizing. Then we're showing the recommended Azure sizing (attached).

We're surprised to see that Azure is recommending smaller sizing for some servers than what we currently use! Curious what you at LF make of that!

For context, we work out of one repository, which is pretty massive (see screenshot), have about 100 Forms Processes, and maybe 200 workflows definitions or so. Import Agent and Email archive are used but only a few profiles in those.

 

LF OnPrem vs Azure Recommendations.xlsx (10.06 KB)
Download
0 0
replied on December 22, 2023

Where did those Azure sizing recommendations come from? Some of them are weird. You should ignore all of the ones recommending D_v2 and F_v2 instances which are ancient at this point. Run new, cheap, burstable Bs_v2 instances instead. Don't go below 8 GB of RAM for any server.

I do see that it recommended an E8bds_v5 for your SQL Server though, which is right on point. 

One important consideration that's not captured in that spreadsheet is the hardware generation of your current on-prem servers. You can easily find that by checking the CPU model(s) in the System Information dialog of Windows. It'll say something like this example from my laptop:

Processor:    11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 1805 Mhz, 4 Core(s), 8 Logical Processor(s)

For an example of the difference a CPU generation can make for certain workloads, see: Microsoft Azure® Esv5 Virtual Machines Delivered Up to 48% Higher Microsoft SQL Server Online Transaction Processing Performance Than Esv4 Virtual Machines

0 0
replied on December 20, 2023

Hi Samuel,

Thanks so much for the response!

All of our current machines are VMs, and we'll be moving them as-is using Azure Migrate (no re-installs needed). We expect it to be pretty easy, the only thing we can think of that will be different will be IP addresses, and we just weren't sure if LF used IP addresses in any sort of way that we'd have to consider.

How do I sign up for the Advanced SP Office Hours on that day?

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...