Although we say that a SQL Azure database is just SQL Server database in the sky, that’s not entirely accurate. Yes, SQL Server and Windows Server are involved, but not like you might think. When you connect to SQL Azure server, and your database, you aren’t connecting to a physical SQL Server. You’re connecting to a simulation of a server. We’d use the term virtual, but it has nothing to do with Hyper-V or application virtualization.
SQL Azure from a logical viewpoint
The endpoint that you connect to with your connection string is a service that’s running in the cloud, and it mimics SQL Server, allowing for all of the TDS and other protocols and behavior you would expect to see when connecting to SQL Server. This “virtual” server then uses intelligence to route your commands and requests to the backend infrastructure that’s really running SQL Server. This intermediate virtual layer is how the routing works, and how replication and redundancy are provided, without exposing any of that complexity to the administrator or developer. It’s this encapsulation that provides much of the benefit of the Azure platform as a whole, and SQL Azure is no different. The logical architecture of how applications and tools connect with SQL Azure.
As a rule of thumb, any command or operation that affects the physical infrastructure isn’t allowed. The encapsulation layer removes the concern of the physical infrastructure. When creating a database, you can’t set where the files will be, or what they will be called, because you don’t know any of those details. The services layer manages these details behind the scenes.
SQL Azure from a physical viewpoint
The data files that represent your database are stored on the infrastructure as a series of replicas. The SQL Azure fabric controls how many replicas are needed, and creates them when there aren’t enough available. There’s always one replica that’s elected the leader. This is the replica that will receive all of the connections and execute the work. The SQL Azure fabric then makes sure any changes to the data are distributed to the other replicas using a custom replication fabric. If a replica fails for any reason, it’s taken out of the pool, a new leader is elected, and a new replica is created on the spot. The physical architecture, relating the different parts of SQL Azure together.
When a connection is made, the routing engine looks up where the current replica leader is located and routes the request to the correct server. Because all connections come through the router, the lead replica can change and the requests will be rerouted as needed.
The fabric can also move a replica from one server to another for performance reasons, keeping the load smooth and even across the farm of servers that run SQL Azure.
What’s really happening behind this encapsulation is quite exciting. The infrastructure layer contains the physical disks and networks needed to redundantly and reliably store the bits that are part of your database. This is similar to the common storage area network (SAN) that many database server infrastructures use. The redundancy of the disks and the tight coupling of the networks provide both performance and reliability for your data.
Sitting on top of this infrastructure layer is a series of servers. Each server runs a set of management services, SQL Server itself, and the SQL Azure fabric. The SQL Azure fabric is the component that communicates with the other servers in this layer to help them communicate with one another. The fabric provides the replication, load balancing, and failover features for the platform.
On top of the servers is a series of services that manages the connection routing (including the firewall features), billing, and provisioning. This services layer is the layer that you connect with and the layer that hides all of the magic.
Deep down under all of these covers, SQL Server really is running. Microsoft has added these layers to provide an automated and redundant platform that’s easily managed and reliable.
Source of Information : Manning Azure in Action 2010
SQL Azure from a logical viewpoint
The endpoint that you connect to with your connection string is a service that’s running in the cloud, and it mimics SQL Server, allowing for all of the TDS and other protocols and behavior you would expect to see when connecting to SQL Server. This “virtual” server then uses intelligence to route your commands and requests to the backend infrastructure that’s really running SQL Server. This intermediate virtual layer is how the routing works, and how replication and redundancy are provided, without exposing any of that complexity to the administrator or developer. It’s this encapsulation that provides much of the benefit of the Azure platform as a whole, and SQL Azure is no different. The logical architecture of how applications and tools connect with SQL Azure.
As a rule of thumb, any command or operation that affects the physical infrastructure isn’t allowed. The encapsulation layer removes the concern of the physical infrastructure. When creating a database, you can’t set where the files will be, or what they will be called, because you don’t know any of those details. The services layer manages these details behind the scenes.
SQL Azure from a physical viewpoint
The data files that represent your database are stored on the infrastructure as a series of replicas. The SQL Azure fabric controls how many replicas are needed, and creates them when there aren’t enough available. There’s always one replica that’s elected the leader. This is the replica that will receive all of the connections and execute the work. The SQL Azure fabric then makes sure any changes to the data are distributed to the other replicas using a custom replication fabric. If a replica fails for any reason, it’s taken out of the pool, a new leader is elected, and a new replica is created on the spot. The physical architecture, relating the different parts of SQL Azure together.
When a connection is made, the routing engine looks up where the current replica leader is located and routes the request to the correct server. Because all connections come through the router, the lead replica can change and the requests will be rerouted as needed.
The fabric can also move a replica from one server to another for performance reasons, keeping the load smooth and even across the farm of servers that run SQL Azure.
What’s really happening behind this encapsulation is quite exciting. The infrastructure layer contains the physical disks and networks needed to redundantly and reliably store the bits that are part of your database. This is similar to the common storage area network (SAN) that many database server infrastructures use. The redundancy of the disks and the tight coupling of the networks provide both performance and reliability for your data.
Sitting on top of this infrastructure layer is a series of servers. Each server runs a set of management services, SQL Server itself, and the SQL Azure fabric. The SQL Azure fabric is the component that communicates with the other servers in this layer to help them communicate with one another. The fabric provides the replication, load balancing, and failover features for the platform.
On top of the servers is a series of services that manages the connection routing (including the firewall features), billing, and provisioning. This services layer is the layer that you connect with and the layer that hides all of the magic.
Deep down under all of these covers, SQL Server really is running. Microsoft has added these layers to provide an automated and redundant platform that’s easily managed and reliable.
Source of Information : Manning Azure in Action 2010
|
|
0 comments
Post a Comment