Embed Size (px)
Citation preview
Loosely coupled: asynchronous processing, decoupling of tiers/components
Fan-out the application tiers to support the workload
Use cache for data and content
Reduce number of requests if possible
Batch together storage/database operations if possible
Partition Azure storage objects across multiple storage accounts if necessary
Design for failure and resilience (Failsafe)
Telemetry instrumentation
Read-only data separated from read-write data
Affinitize application and database as scale unit
Compute Instance CPU (GHz) Memory
Xsmall (A0) 1 768mb
Small (A1) 1.6 1.7GB
Medium (A2) 2 x 1.6 3.5GB
Large (A3) 4 x 1.6 7GB
Xlarge (A4) 8 x 1.6 14Gb
A6 4 x 1.6 28GB
A7 8 x 1.6 56GB
• Structured or un-structured data
• Persisted or temporary data
• Where to place the data•
•
Storage Offering Purpose Maximum Size
Local StoragePer-instance temporary
storage250GB to 2TB
Windows Azure
StorageDurable storage for.....
BlobLarge binary objects such
as video or audio200GB or 1TB
Table Structured data 100TB
Queue Inter-process messages 100TB
SQL DatabaseRelational Database
Management System150GB
• System Drive (C:\)
• Temporary Storage (D:\)
• Small test databases including tempdb may be placed in C: (disable write caching)
• Single storage account for all data disks
• Attached Disks•
•
VM Size CPU Cores Memory# Data
Disks *Max IOPS
SQL Server
Edition
Extra
smallShared 768 MB 1 1 x 500
Not
recommended
Small 1 1.75 GB 2 2 x 500 Any
Medium 2 3.5 GB 4 4 x 500 Any
Large 4 7 GB 8 8 x 500 Any
Extra
large8 14 GB 16 16 x 500 Any
A6 4 28 GB 8 8 x 500 Any
A7 8 56 GB 16 16 x 500 Any
(*) Each persistent data disk up to 1 TB
Virtual Machine Sizes and SQL Server Editions
SQL Azure Sharding
Time
Resources available
to an individual DB
0
CPU Max possible
Multi-tenant resource sharing environment
Reservation
size
Processor
units
Concurrent
active
requests
(workers)
Sessions Data IO
(IOPS)
Memory
(GB)
L (P2) 2 400 4000 300 16
M (P1) 1 200 2000 150 8
Data access to Azure SQL Database introduces additional complexity around:
Microsoft Enterprise Library Transient Fault Handling Application Block
•
•
•
•
•
•
•
•
•
•
ResourceMax. value per
transaction/session
Max. value per
machineSoft throttling limit Hard throttling limit
Worker ThreadsNA 1000 180 900
Database Size150 GB per partition NA None 100% (150 GB or upper
limit for customer)
Physical Database
Space
NA Total space on
machine
None 90%
Log Bytes Used2 GB per transaction 500 GB NA NA
Transaction Log
Length
20% of total log space
(= 100 GB)
500 GB NA NA
Lock Count1 milllion per
transaction
NA NA NA
Blocking System
Tasks
20 seconds NA NA NA
Temp DB Space5 GB NA None 5 GB
MemoryNA NA None 16 MB for 20 seconds
•
•
•
SQL
Azure
Blog Post: Testing Client Latency to SQL Azure
From\To (ms) North-Central US South-Central US North Europe West Europe East Asia South-East Asia
North-Central US 5 47 101.3 112.1 198.8 227.2
South-Central US 39.6 13.7 121 116.9 181.1 209.6
North Europe 104.5 122.8 4.5 28.9 287.7 317.3
West Europe 119.7 127.2 29.8 5.8 310.8 341.4
East Asia 202.7 196.2 290.3 317.8 1.9 33.5
South-East Asia 230.8 230 318 350.2 32.8 2.2
SELECT t.ID, t. RECORD FROM Customer_MVMT t
Azure VM Azure Storage
App
ServerAttached
DiskSQL Server
Memory
Pool
Local Disk
Cache
Laptop
Client
Seattle Azure US North Data Center
Azure StorageAzure VM
App
Server
Azure VM
SQL ServerMemory
Pool
Local Disk
Cache
Laptop
Client
Seattle Azure US North Data Center
• App Server and SQL Server are in the same box
• Test Result: 110 seconds (avg)
• AppServer and DB Server are in two separate VMs
• Test Result: 150 seconds (avg)
Azure VM SQL Database
App
ServerDB
Data
Laptop
Client
Seattle Azure US North Data Center
• Data is stored in Azure SQL Database
• Test Result: 240 seconds (avg)
Attached
Disk
-
-
-
Client
Component
Client
Component
Client
Component
Client
Component
Transaction Management
Client
Component
(50)
(URI/50)
(URI/25)
50
25
Provisioning
WAS
BLOB
WAS
BLOB
SQL Data Sync
Geo-Replication
Application
Services
Application
Services
Provisioning
BLOB BLOB
Provisioning
Repository
Provisioning
Service
Management
PortalMonitoring
Queue 1
Queue 2
Queue 3
Worker
Role
Application
Worker
RoleWorker
RoleWorker
RoleWorker
Role
WAS
BLOB
BLOB
BLOB
Windows Azure Suitable Migration Scenarios Things to watch for
Compute Virtual machines • Better compatibility with on-prem
environment
• Easy and fast migration path for existing apps
• minimal/zero code changes
• Users still responsible for OS level maintenance
(e.g. patching, config, etc)
• Limited out-of-the-box auto-scale feature
support
• Code review is recommended. (e.g. “sticky
session” – solution 1, solution 2)
Websites/Cloud
Service
• PaaS services, users only need to focus on
coding for business logic
• Auto-scale feature support
• Suitable for brand new apps from scratch
• Websites with clean codes (no native dll, no
special IIS configuration)
• Requires some code changes to existing apps
• Some learning curve for new users to adopt the
SDKs
• Applications are bound to Windows Azure
platform
Data
Services
SQL database • Database PaaS service. Users don’t need to
setup/maintain their own DB server.
• Built-in HA
• Competitive pricing
• Leveraging existing tools (SSMS, etc) for DBA
and developers
• Size limitation (150GB max)
• Not 100% compatible with SQL Server, might
require some DB/code changes
• Need to evaluate customer’s performance
requirements on DB
Blob • Highly scalable storage for files
• We can also use Azure drive to attach disks to
VM
• Need to leverage Azure SDK or web service API
to access blob storage
• Each VM can have maximum 16 disks attached
(1TB max for each disk)
Networks Virtual network • Compatible VPN devices already in use
• On-prem network matches the requirements
• At least one server with public IP not behind NAT
• Ports for IKEv2 on the gateway server should be
opened.
Q&A
ios (version 6 or below):
Please input the below URL:
http://aka.ms/WAD383
Other platform:
QR Code:
