It camp 2015 how to scale above clouds limits, radu vunvulea

@ITCAMPRO #ITCAMP15Community Conference for IT Professionals

How to scale above clouds limits

Radu Vunvulea

Technical Lead, iQuest Group

@RaduVunvulea

vunvulearadu.blogspot.com


WHY SCALING IS IMPORTANT


WHY SCALING IS IMPORTANT

8000m – Cirrus

6000m – Cumulonimbus

4000m – Altostratus

2000m - Nimbostratus


Understand that scaling and failover

is not only cloud provider’s responsibilities,

is also our yours

Goal


RADU VUNVULEA MCTS MCP BANK HOME AUTOMATION

MVP IoT

AUTOMOTIVE PHARMA

LEAN AND AGILE E-COMMERCE

WEB&SPA iQuest

AZURE JAVASCRIPT VUNVULEARADU.BLOGSPOT.COM

MOBILE DOTNET @RaduVunvulea

WCF WPF ENTHUSIASTIC


Many thanks to our sponsors & partners!

GOLD

SILVER

PARTNERS

PLATINUM


• Identify limitations

• Investigate different problems

• Overview on different solutions

Agenda


Hardware

Capabilities

Functionality

App Design

Types of limitations


Hardware

Capabilities

Functionality

App Design



Hardware

Capabilities

Functionality

App Design



Hardware

Capabilities

Functionality

App Design



Hardware

Capabilities

Functionality

App Design



STORAGE BANDWIDTH


Storage bandwidth

Target throughput for single blob

• 60MB/s

• 500 requests/s

Per storage account

• 30Gb/s


Storage bandwidth


• 60MB/s

Can we still have 10MB/s for

each client?


Storage bandwidth


• 60MB/s

Can we still have 10MB/s for

each client? NO


Storage bandwidth

Solutions

• CDNs

• Content replication


Storage bandwidth

Solutions

• CDNs

• Content replication


STORAGE CAPACITY


Storage capacity

Storage account capacity

• 500TB

Storage accounts

• 100 per subscription


Storage capacity


• 500TB

What happens in 1 year if we produce

2TB of data per day?


Storage capacity


• 500TB

What happens in 1 year if we produce

2TB of data per day? Out of space


Storage capacity

Solution:

• Work with multiple storage

accounts

To be able to do this our application

needs to be able to store a list of

storage accounts, not only one


Configuration


• CSDEF

• SQL Database

• Azure Table

• Azure Storage

Configuration


• CSDEF

• SQL Database

• Azure Table

• Azure Storage

–Blobs

–XML Format

Configuration


HOW LONG WE CAN SCALE?

Adding more and more instances and resources is a good solution.

Can we quarantee the quality of our service when we are adding more and more

resources?

How much we can stretch in this way?


Adding more instances







• Soon this will break, why?

–The quality of service will not remain the same by adding

more and more resources

–Managing a large infrastructure will

be a nightmare

–Our confidence will be lower and

lower



• Soon this will break, why?

–The quality of service will not remain the same by adding

more and more resources

–Managing a large infrastructure will

be a nightmare

–Our confidence will be lower and

lower

• In the end the system will BREAK



Scaling Unit

• Grouping resources together and defining the

quality attributes of that scaling unit

• When the limits are hit

another scaling unit is

added, without adding

more resources to the

current one(s)


Scaling Unit


Scaling Unit

20.000 + 1


Scaling Unit

20.000 + 20.000+ 1


FAILOVER MECHANISM

What should we do when we need better SLA?

Or a failover mechanism…

… to be able to be up and running even during and after a major disaster…


• One or more services from

current region are going

down

• What should we do?

Failover mechanism


• Adding resources in another region

Failover mechanism



–Before

–During

–After

a disaster

Failover mechanism



–Before, is great. But with extra costs

–During, we can lose a part of data

–After, is to late. We are not the only one in this situation

a disaster

Failover mechanism


ACTIVE-PASSIVE


Active - Passive

• Active is upOnly storage is allocated

on the passive


Active - Passive

• Active is up


Active - Passive

• Active is down


ACTIVE-ACTIVE


Active - Active

• Active is up75% of computation power is

allocated on passive


Active - Active

• Active is up


Active - Active

• Active is down


Active-Active

• Minimum downtime

• Resource reservation

• You pay for resources that you don’t use

• Data sync can be a nightmare

Active-Passive

• A few seconds (minutes) downtime

• No resources reservation

• No extra costs (except storage)

• Data sync can be a nightmare

Active – Active & Active - Passive




WHAT ABOUT COMMUNICATION

It is not enough to have a failover mechanism for storage and computing

If there is no communication channel between the components then by they are used…


Communication Channel



• Active-Active

• Active-Passive



• Active-Passive



• Active-Passive



• Active-Active


CONCLUSION


• We should scale our system in different ways, not

only by adding more instances

• Scaling Unit is a good way for scaling

• Active-Active can be useful but is expensive and can

be a nightmare

Conclusion


Q & A


THANK YOU

@Radu Vunvulea

[email protected]

www.vunvulearadu.blogspot.com


TAKE A LOOK ON SCALING UNIT CONCEPT

Next steps


THANK YOU

It camp 2015 how to scale above clouds limits, radu vunvulea

Technology

itcamp15community conference

multiple storage accountsto

list of storage accounts

tb of data

different solutions

public cloud infrastructures

professionals5many thanks

microsoft private