Clustered MegaServers

I assume this term is used for clustering all your Federated Server members.
- Does each node have a SQL Instance installed? If yes, I assume 1 virtual
instance of sql is treated as the main, and all federation members are
configured as linked servers.
- When I create my partitioned views, are the servers connected via linked
servers? Remote servers?
- When issuing a select, how do I use the (nolock) or read-uncommitted
isolation level across linked servers? I don't want to add nolock to a view
that is updateable. How to deal with this? I definitely do not want my select
blocking dml...
- Any tips or tricks or gotchas with this architecture?
- I haven't been able to find definitive documentation on this architecture,
anyone know of some good links or books?
Thanks in advance,
ChrisB
Looks like the technology you are looking for is linked servers, not
clustered servers. Clustered servers is another technology to achieve high
availability. For example, a popular cluster configuration has 2 servers,
one active and one passive, but SQL Server is only running on the active
node. The passive is doing nothing, just waiting to automatically replace
the active node in case this has a problem.
Documentation for both technologies are on the Books Online.
Regards,
Ben Nevarez
"Chris" <Chris@.discussions.microsoft.com> wrote in message
news:48E011E5-DAD0-48A0-B059-2DBFAA2975C7@.microsoft.com...
> I assume this term is used for clustering all your Federated Server
> members.
> - Does each node have a SQL Instance installed? If yes, I assume 1 virtual
> instance of sql is treated as the main, and all federation members are
> configured as linked servers.
> - When I create my partitioned views, are the servers connected via linked
> servers? Remote servers?
> - When issuing a select, how do I use the (nolock) or read-uncommitted
> isolation level across linked servers? I don't want to add nolock to a
> view
> that is updateable. How to deal with this? I definitely do not want my
> select
> blocking dml...
> - Any tips or tricks or gotchas with this architecture?
> - I haven't been able to find definitive documentation on this
> architecture,
> anyone know of some good links or books?
> Thanks in advance,
> ChrisB
>
|||Ben - perhaps you should take a look at this article?
http://www.microsoft.com/technet/pro...msam.mspx#EIAA
Excerpt:
A cluster of SQL Server SMP nodes can do even more. In one benchmark, HP
demonstrated a 32-node cluster of 8-way Xeon processors supporting more than
575,000 concurrent users, and a 53-terabyte database processed 709,220
Transaction Processing Council Benchmark C (TPC-C) transactions per minute
(tpmC), ...
Chris
"Ben Nevarez" wrote:

> Looks like the technology you are looking for is linked servers, not
> clustered servers. Clustered servers is another technology to achieve high
> availability. For example, a popular cluster configuration has 2 servers,
> one active and one passive, but SQL Server is only running on the active
> node. The passive is doing nothing, just waiting to automatically replace
> the active node in case this has a problem.
> Documentation for both technologies are on the Books Online.
> Regards,
> Ben Nevarez
>
>
> "Chris" <Chris@.discussions.microsoft.com> wrote in message
> news:48E011E5-DAD0-48A0-B059-2DBFAA2975C7@.microsoft.com...
>
>
|||What you are talking about is called a Server Federation and is more akin to
Network Load balancing, which is a scale-out solution. SQL Server Failover
Clustering uses Server Clusters and is a High Availability solution, not a
scaling solution.
Federated Server help scale out by distributing the load across multiple
servers; however, unlike NLB where each web server has an exact copy, each
SQL Server in a federation has an exact copy of the structure, but
partitions the data.
For example, say we have a Customer table. The A through M customers could
be saved to one installation and the N through Z customers to a second. You
could partition more finely and scale out to additional servers in the
Federation. You also use linked servers so that each installation can speak
and pass through to the others.
You would also create Distributed Partitioned Views on each copy of the
database that reassembles the data through UNIONs against the Linked Server
definitions so that each server could represent that view of the data.
Clients would be redirected to a server and be able to query this UNIONed
VIEW, but, more importantly, through the partitioning and CHECK CONSTRAINTs
against the tables, CRUD operations against the VIEW would be redirected to
the appropriate partitioned table.
Pretty complex stuff. Luckily, with SS2K5, Partitioned Tables along with
Partitioned Indexes will make this much easier to implement.
Finally, each server that is a member of a Federation, could in essence be a
Virtual Failover Cluster installation, for High Availability.
In W2K3, both Enterprise and Datacenter Server Editions can support up to 8
nodes within a single Failover Cluster environment. With this, along with
Server Federations, some pretty complex "Clustered MegaServers" could be
envisioned.
Best of luck.
Sincerely,
Anthony Thomas

"Ben Nevarez" <bnevarez@.sjm.com> wrote in message
news:%23a9SSwZ6FHA.1720@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> Looks like the technology you are looking for is linked servers, not
> clustered servers. Clustered servers is another technology to achieve high
> availability. For example, a popular cluster configuration has 2 servers,
> one active and one passive, but SQL Server is only running on the active
> node. The passive is doing nothing, just waiting to automatically replace
> the active node in case this has a problem.
> Documentation for both technologies are on the Books Online.
> Regards,
> Ben Nevarez
>
>
> "Chris" <Chris@.discussions.microsoft.com> wrote in message
> news:48E011E5-DAD0-48A0-B059-2DBFAA2975C7@.microsoft.com...
virtual[vbcol=seagreen]
linked
>
|||" Luckily, with SS2K5, Partitioned Tables along with
Partitioned Indexes will make this much easier to implement."
Partitioned tables in SQL05 are partitioned within a single database.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:%23DzgB1$6FHA.1140@.tk2msftngp13.phx.gbl...
> What you are talking about is called a Server Federation and is more akin
> to
> Network Load balancing, which is a scale-out solution. SQL Server
> Failover
> Clustering uses Server Clusters and is a High Availability solution, not a
> scaling solution.
> Federated Server help scale out by distributing the load across multiple
> servers; however, unlike NLB where each web server has an exact copy, each
> SQL Server in a federation has an exact copy of the structure, but
> partitions the data.
> For example, say we have a Customer table. The A through M customers
> could
> be saved to one installation and the N through Z customers to a second.
> You
> could partition more finely and scale out to additional servers in the
> Federation. You also use linked servers so that each installation can
> speak
> and pass through to the others.
> You would also create Distributed Partitioned Views on each copy of the
> database that reassembles the data through UNIONs against the Linked
> Server
> definitions so that each server could represent that view of the data.
> Clients would be redirected to a server and be able to query this UNIONed
> VIEW, but, more importantly, through the partitioning and CHECK
> CONSTRAINTs
> against the tables, CRUD operations against the VIEW would be redirected
> to
> the appropriate partitioned table.
> Pretty complex stuff. Luckily, with SS2K5, Partitioned Tables along with
> Partitioned Indexes will make this much easier to implement.
> Finally, each server that is a member of a Federation, could in essence be
> a
> Virtual Failover Cluster installation, for High Availability.
> In W2K3, both Enterprise and Datacenter Server Editions can support up to
> 8
> nodes within a single Failover Cluster environment. With this, along with
> Server Federations, some pretty complex "Clustered MegaServers" could be
> envisioned.
> Best of luck.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Ben Nevarez" <bnevarez@.sjm.com> wrote in message
> news:%23a9SSwZ6FHA.1720@.TK2MSFTNGP09.phx.gbl...
> virtual
> linked
>