Welcome to Cloud View! With the new year 2020 coming closer, the industry is firmly looking towards the future. Cloud news is full of predictions for the year ahead and here’s a quick selection we picked for this week’s reading. Predictions Industry Insights Telcos embrace containers Gartner predicts that over 75% of global companies will […]


LATEST BLOG

Business Needs:

Our goal is to identify whether Amazon SQL Server RDS Service provides elastic , highly available , Scalable and operationally efficient solution for our use case. We are evaluating options to migrate our read/write heavy production SQL Server database to amazon SQL Server RDS. We have pretty high throughput needs for few hours a day for few months in a year ,which is mission critical for our business success. Any downtown during peak usuage would be catastrophic for our business. We are evaluating pros and cons of moving to amazon RDS with provisioned IOPS.

Caveats of AWS RDS SQL Server:

These information we gathered while working with SQL Server RDS.

Feature Name Yes/No Description
SQL Server 2016 Support No Microsoft says SQL Server 2016 comes with very rich feature set and ton on OLTP Enhancements
Native Backup Restore Yes AWS RDS Released this feature a week ago , which makes moving databases across environments lot more easier.
Elastic IOPS No Storage and IOPS needs to be incremented linearly for higher performance. You can’t get higher IOPS without increasing storage.
Elastic Storage No Scaling Storage is not an option after launching an instance
RAID Support No We usually have RAID 10 for production workload and RDS doesn’t have options to configure RAID
Point in Time Restore on Same Instance No You can’t do Point in Time Restore on the existing database. You have to spin up new Instance
AlwaysOn Availability Groups No This provides ability to failover group of databases to your secondary instance
Mirroring Yes Mirroring is Deprecated feature and its replaced with AlwaysOn Availability Groups
Linked Servers from RDS No But Linked Servers to RDS is Allowed.
Service Broker No Comes handy for services

  No Admin privileges. You can’t execute normal sql server system stored procedures and you need to work with options groupand parameters group to modify configuration. You can’t execute sp_configure to change configurations.

AWS SLA Summary
AWS Service SLA Service Credit Pct SLA Resource
RDS 99.95% Less than 99.95% but equal to or greater than 99.0% 10 % https://aws.amazon.com/rds/sla/
RDS 99.95% Less than 99.0% 25 % https://aws.amazon.com/rds/sla/
S3 99.9% Equal to or greater than 99.0% but less than 99.9% 10 % https://aws.amazon.com/s3/sla/
S3 99.9% Less than 99.0% 25 % https://aws.amazon.com/s3/sla/
EC2 99.95% Less than 99.95% but equal to or greater than 99.0% 10 % https://aws.amazon.com/ec2/sla/
EC2 99.95% Less than 99.0% 30 % https://aws.amazon.com/ec2/sla/
Route 53 100 % 5 – 30 minutes in a Billing Cycle 1 day Service Credit https://aws.amazon.com/route53/sla/
Route 53 100 % 31 minutes – 4 hours in a Billing Cycle 7 days Service Credit https://aws.amazon.com/route53/sla/
Route 53 100 % More than 4 hours in a Billing Cycle 30 days Service Credit https://aws.amazon.com/route53/sla/
SLA Percentages
Availability % Downtime/Month Downtime/Week Downtime/Day
90% (“one nine”) 72 hours 16.8 hours 2.4 hours
95% 36 hours 8.4 hours 1.2 hours
97% 21.6 hours 5.04 hours 43.2 minutes
98% 14.4 hours 3.36 hours 28.8 minutes
99% (“two nines”) 7.20 hours 1.68 hours 14.4 minutes
99.5% 3.60 hours 50.4 minutes 7.2 minutes
99.8% 86.23 minutes 20.16 minutes 2.88 minutes
99.9% (“three nines”) 43.8 minutes 10.1 minutes 1.44 minutes
99.95% 21.56 minutes 5.04 minutes 43.2 seconds
99.99% (“four nines”) 4.38 minutes 1.01 minutes 8.66 seconds

  Useful Links Cloud Provider Service Availability https://cloudharmony.com/status

According to AWS Documentation The first time a DB instance is started and accesses an area of disk for the first time, the process can take longer than all subsequent accesses to the same disk area. This is known as the “first touch penalty.” Once an area of disk has incurred the first touch penalty, that area of disk does not incur the penalty again for the life of the instance, even if the DB instance is rebooted, restarted, or the DB instance class changes. Note that a DB instance created from a snapshot, a point-in-time restore, or a read replica is a new instance and does incur this first touch penalty.

Reference : http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html.
I captured number of cached pages per database on our SQL Server RDS Instance and rebooted the instance and captured cached pages again. Based on the documentation, the cached pages should be available and shouldn’t be affected by Reboot process. Its such a neat feature which makes life lot easier for DBA’s to respond to unexpected situations. But I noticed significant differences between the number of  cached pages before and after reboot.

Cached Pages Before and After SQL Server RDS Reboot
DBName Bef_Buf_Pages Size_MB Aft_Buf_Pages Size_MB
DatabaseOne 558482 4363 596 4
DatabaseTwo 1017 7 487 3
DatabaseThree 609 4 201 1
master 190 1 107 0
model 18 0 37 0
msdb 882 6 284 2
rdsadmin 1253 9 87 0
DatabaseFour 133 1 59 0
Resource Database 1877 14 319 2
tempdb 779280 6088 123 0

For DatabaseOne , Cached Pages dropped from 558482 to 596. I am not sure whether others have encountered the same issue. Not sure what to think of the First Touch Penalty Promise to keep the cache intact. Maybe its not true for SQL Server RDS. 🙂

Remote Host Identification SSH Error
 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:oFgx2U4Q0KUxtFnouxHYJdLyH6qDbX/rKtsg
Please contact your system administrator.
Add correct host key in /Users/username/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/ username /.ssh/known_hosts:1
RSA host key for 54.214.1.26 has changed and you have requested strict checking.
Host key verification failed.
Edit known_hosts and remove the offending host entry and SSH into Host Again
 

username -MBP:.ssh username $ vi known_hosts
username -MBP:.ssh username $ ssh -i Key.pem ec2-user@54.214.1.26
The authenticity of host ‘54.214.1.26 (54.214.1.26)’ can’t be established.
ECDSA key fingerprint is SHA256:2VcR+DiKNRwyQwZ2LqtZ6EHxQYv5MWMAsrrI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘54.214.1.26’ (ECDSA) to the list of known hosts.
Last login: Fri Jul 29 23:08:35 2016 from
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-ami/2016.03-release-notes/
4 package(s) needed for security, out of 4 available
Run “sudo yum update” to apply all updates.

POPULAR POSTS

CloudIQ is a leading Cloud Consulting and Solutions firm that helps businesses solve today’s problems and plan the enterprise of tomorrow by integrating intelligent cloud solutions. We help you leverage the technologies that make your people more productive, your infrastructure more intelligent, and your business more profitable. 

US

626 120th Ave NE, B102, Bellevue,

WA, 98005.

 sales@cloudiqtech.com

INDIA

Chennai One IT SEZ,

Module No:5-C, Phase ll, 2nd Floor, North Block, Pallavaram-Thoraipakkam 200 ft road, Thoraipakkam, Chennai – 600097


© 2019 CloudIQ Technologies. All rights reserved.

Get in touch

Please contact us using the form below

USA

626 120th Ave NE, B102, Bellevue, WA, 98005.

+1 (206) 203-4151

sales@cloudiqtech.com

INDIA

Chennai One IT SEZ,

Module No:5-C, Phase ll, 2nd Floor, North Block, Pallavaram-Thoraipakkam 200 ft road, Thoraipakkam, Chennai – 600097

+91-044-48651163