November 7, 2017 at 6:26 pm
Hi DBA Gurus,
I've been assigned a task first to propose a plan including scripts and Time for the below scenario. Any help and Time is appreciated.
We have 6 standalone SQL instances, no clustering no always on etc. which need to be moved to Amazon EC2 instances, not Amazon RDS. So I'll be manually installing SQL Server 2014 on the AWS instances, will be copying the Full Backups to S3 and Restoring the full backups on the AWS EC2 instances with no recovery. The Management would like to use this as a DR source. How to keep all those DBs ( about 300 - Total size 2 TB ) in sync with the on premise ( Primary DB's ). We cannot have clustering or Always ON . LogShipping and Mirroring is a preferred approach. How to automate it with scripts ? or any other ideas?
Thanks Again
November 9, 2017 at 7:20 am
sqlguy80 - Tuesday, November 7, 2017 6:26 PMHi DBA Gurus,I've been assigned a task first to propose a plan including scripts and Time for the below scenario. Any help and Time is appreciated.
We have 6 standalone SQL instances, no clustering no always on etc. which need to be moved to Amazon EC2 instances, not Amazon RDS. So I'll be manually installing SQL Server 2014 on the AWS instances, will be copying the Full Backups to S3 and Restoring the full backups on the AWS EC2 instances with no recovery. The Management would like to use this as a DR source. How to keep all those DBs ( about 300 - Total size 2 TB ) in sync with the on premise ( Primary DB's ). We cannot have clustering or Always ON . LogShipping and Mirroring is a preferred approach. How to automate it with scripts ? or any other ideas?
Thanks Again
Are you talking about high availability, disaster recovery or something else? Do you want to use the Amazon EC2 instances as active databases if your primary falls over or will it be used to store data that can be used to restore your primary instances/databases? Mirroring and Log Shipping can be defined as high availability solutions but you were talking about disaster recovery.....
Here you need to define a Restore Point Objective(RPO) and Restore Time Objective(RTO) before you can even begin to consider a solution. You need to be aware that if you suffer a catastrophic incident on your primary instances that you will loose data, it is just a matter of how much is allowable. Once those are defined you can start considering technologies.
Obviously here I would implement HAGs but you seem very tied on that point. Is there a reason for that?
November 9, 2017 at 8:30 am
Hi Keva,
Thanks for the message.
yes, this is for DR to start off and we are ok with 1-2 hours , EC2 DR instances being out of sync with the Primary Datacenter.
We don't have the time or budget to change the architecture , the App is old and works with only standalone instance name.
November 9, 2017 at 8:47 am
sqlguy80 - Tuesday, November 7, 2017 6:26 PMHi DBA Gurus,I've been assigned a task first to propose a plan including scripts and Time for the below scenario. Any help and Time is appreciated.
We have 6 standalone SQL instances, no clustering no always on etc. which need to be moved to Amazon EC2 instances, not Amazon RDS. So I'll be manually installing SQL Server 2014 on the AWS instances, will be copying the Full Backups to S3 and Restoring the full backups on the AWS EC2 instances with no recovery. The Management would like to use this as a DR source. How to keep all those DBs ( about 300 - Total size 2 TB ) in sync with the on premise ( Primary DB's ). We cannot have clustering or Always ON . LogShipping and Mirroring is a preferred approach. How to automate it with scripts ? or any other ideas?
Thanks Again
Just keep in mind that keeping 2 TB of data in sync with any other location is going to require significant network bandwidth if there's much in the way of change volume. Find out how much data changes in a given time period before you go down this road, because you may discover that 1 to 2 hours given existing network infrastructure just isn't even remotely close to possible. You need to know that BEFORE you go down that road. On the other hand, you may also discover that the change volume is low enough that you can be perhaps only minutes out of sync. Also be sure to think about any existing overnight data-intensive things like ETL, data loads, bulk imports, etc., and keep in mind that such data intensive workloads may not be able to be kept in sync as quickly as the daytime workload.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
November 9, 2017 at 8:55 am
thanks. The changes are not that much ... `5-10 GB that's it per day on some DBs
November 9, 2017 at 9:05 am
sqlguy80 - Thursday, November 9, 2017 8:55 AMthanks. The changes are not that much ... `5-10 GB that's it per day on some DBs
Okay, but in what timeframe? If that's business hours only, say 8 am to 5 pm, that just 9 hours, or up to about 1.1 GB/hour. You'd need network bandwidth into Amazon of at least that much, independent of monitoring traffic and other usage... Understand that a 1 Gigabit network card can only usually achieve about 800 to 900 megabits per second, assuming you have a dedicated network path, and ample disk i/o speed to keep the data flowing. Add in SANs and network switches, routers, and the internet itself, and suddenly that rate is a considerably smaller fraction thereof, so it doesn't take a lot of traffic to require a bump in bandwidth, or even an entirely private network path. If you have multiple databases with that same kind of volume, again, you need to do some conservative math and determine what kind of bandwidth you need to keep network latency low enough to allow the technology involved to actually work, whether it's log-shipping, mirroring, or even replication.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply