Tip:
Highlight text to annotate it
X
Okay, we'll start through these different Configurations by looking
at Clustered SQL Server and also Mirrored SQL Server.
If you remember, I mentioned
that the AF Clients talk to the AF Server by means
of this thing that we call the AF SDK.
This AF SDK has logic built into it
that, well first of all, will detect if there's
a lack of communication in here. If that communication fails
then there's some retry logic that's built into the
AF SDK. So, what that means is that any kind of
a technology that allows SQL
Server to fail over in some way to another copy of
SQL Server, well, we'll support that just by the
nature of the design. So, in a Clustered
environment, this Clustered SQL Server works the following way.
You start with two SQL Server Boxes.
Each Box is going to be sharing in common
this hard drive, and this is all using specialized hardware
that you need to buy, you know, apart from you just,
your normal considerations for running SQL Server.
So, with the shared hard drive, what we end up
doing is having a fail-over event --
you know, let's say this Option
or that that Server there fails, then there's going to be a fail-over
that's on the order of maybe minutes or so --
seconds or minutes. And, when that happens, of course,
its only going to fail-over if
nothing has happened to this drive right here. So, if
that Disk Array is still operating
then the fail-over is going to occur. And the fail-over occurs
in such a way that this, you know, this AF
Communication here, and the Clients communicating with it,
well, they'll, they'll just keep retrying. So, that
level fail-over is, is just fine. As you can
see, we've got very little to do with it at that point,
other than the fact that we built into the SDK this
re-try mechanism. Now, let's go take a look
at that Table and see what this means in terms of the,
you know, the different capabilities here. First of all,
let's, let's discuss what we mean by HA Writes.
What we mean by HA Writes is does
the system have the ability to write to the system of record,
essentially to the AF Database, if there's some
kind of a failure with a component in that Cluster?
In this example, with SQL Cluster
the disruptive event
would be if this Box here were to fail.
So, if, you know, this is the Disruptive Event. If that
fails, can we do an HA Write?
Can we continue to write to the Database? Well,
as you can see, just by the nature of this, after that couple of
minute delay in which we will buffer up and
re-try, you know, to, to do those, those
Reads and Writes -- if that occurs,
then, yes, the SQL Cluster will support doing HA
Writes. So, with a Clustered
environment, we'll be able to Read and we'll, and we'll be able to Write.
Now the, the Load Balanced Reads, what we
mean by that is, is there some
mechanism in place in which we're going to
automatically kind of divide up the resources
if there's a lot of Reads
that are in excess of maybe what the current capacity is?
Is there some way to kind of Load Balance that across different Servers?
Well, in the case of the SQL Cluster, no, that's not an option.
That's not something that SQL Server's
going to do for us automatically. Now, the reason
for that is real simple. If we go back and look at the illustration, you know,
just because we have two computers,
they're both going to be accessing this same Drive,
and they're not even doing it at the same time, of course. One just
fails over to the over, so there's no reason that this is going to do any kind of
Load Balancing or, you know, sharing the Load across,
across different
devices. There just aren't any there. So, the maximum
distance that we support is something in the order of tens of meters.
As you can see listed here, we do provide
Read Access and Read Write Access during the upgrade
of, of both SQL Server and the Operating
System. So, for example, if, you know,
if one of those machines is down then the other will go ahead and take over.
Obviously, you won't do 'em both at once, or you won't have Read Write Access,
but, since they share that Disk Array,
that is something that's a capability.
Now, this next one here is a
Provisional No. This is Read Write Access during the AF Upgrade.
And, let me explain that. By doing
an AF Upgrade, that essentially stops the AF Server.
If we go back to our illustration, we can see
that with that, with that AF Server
stopped -- you know, here's our AF Server --
if that's stopped for an Upgrade, and you do have to stop
the AF Server in order to do that Upgrade,
well, there's not going to be any Read Write Access
down to this machine, even if these are available.
Well, there -- I say that's
provisionally what, what our answer is no.
But what would happen if, for example, you
took a couple of these Servers and pointed
them all to the same database. So, now I've got
one, two, three different AF Servers.
Each one of these AF Servers is pointing to
exactly the same database.
So, these are all pointing to that same SQL Server
Database, that same PI AF, or PI FD
Database in SQL Server. Well, as I mentioned earlier,
that is a, a completely legitimate
configuration. You can install AF on as many Boxes
as you want, and point them all to the same Server,
and if that's the case, then
you can do an Upgrade, kind of a rolling Upgrade.
You know, first Upgrade this here, then Upgrade this one,
then Upgrade this one, and as you're doing these Upgrades to the
AF Servers, the other Servers will continue
to grant Read Write Access to any Users who need them.
Now, if you are going to implement something like that,
you are going to have to have some kind of a Load Balancer layer
right about at here between the Clients --
remember, the SDK is what the Clients use -- so something
between the Clients that will distribute the,
the Load to whichever AF Server's available.
And, that's something that you can do just with --
straight with what Microsoft provides, the Network Load Balancer from
Microsoft, where you can get a third party
Load Balancer to do that. Okay, now back
to our List of Features. Is there any
special hardware required for this Configuration?
Well, as I mentioned, the, that Clustered
SQL Server is something that requires special hardware.
It's the, the Array that's going to
be shared by the two computers. And finally,
the SQL Server Addition that's going to be required for SQL Server
Cluster is going to be the Standard Edition, so
SQL Server Express is not supported in a Clustered environment.
Now next up would be the
Mirrored SQL Server, and, as we
did with the SQL Server that's in a Clustered Environment,
you know, this is something that, I guess, we really can't
take much credit for because, as I mentioned before,
we have the logic built in so that if there is
ever a disconnect, you know, at this Level right
here, if that disconnect occurs, we're simply going to
retry. So, we're counting then on
Microsoft providing some kind of a fail-over mechanism.
Now, with Mirrored SQL Server, the fail-over mechanism
involves two completely identical copies
of the AF Database. These are going to be on
two copies of SQL Server. You know, this copy here, this copy
here. They're both going to have the exact
same Mirrored Information on them. As I understand it,
there is a, a third computer required,
a Witness that is, establishes a,
I guess what they call a quorum, for this to all occur.
But, as I said, we kind of treat it like a Black Box
at OSI because, you know, this is something you're going to have to
configure with the help of Microsoft, and
it is a mechanism that we fully support. You know, we take
advantage of it through, by -- or by means
of these re-tries that occur if there
is some kind of a, a lack of availability or a lack
of response. Okay. So, let's see how this
lines up to that Table that we've been discussing.
We're talking about now, the, the Mirrored
SQL Server. And so, are we avail...
Or is it available to do these HR Writes? Well, again,
an HA Write is, what we mean by that is
do we have the ability to Write if the,
you know, the guarded-against occurrence
occurs? And, in this case, the
occurrence would be if one of these machines fails,
if one of these machines fails because it's Mirrored,
there's an automatic, or nearly automatic fail-over here,
so the Writes would continue. So, that's
something that will -- you know, we do support.
We, of course, support Reads as well for the Mirrored.
Are these -- is there any Load Balancing built into this? No.
Again, it's, these, these are two separate
machines that, they don't share hardware
but there's, you know, there's nothing special about them that's going to
do any Load Balancing that a single machine wouldn't do.
This does have the advantage that you can separate these
things further, geographically.
Also, these do support the Reads
and the Reads Writes during Upgrades of the Operating System
and SQL Server because they are independent machines.
Now, as with the Clustered Environment, we should point out
that this, whether we support the Read and Write during the
AF Upgrade or not, that really is something that's --
needs to be qualified. If you have
just a single AF Server configured in
that Environment, then no, we will not support Reads and Writes during an
Upgrade, you know, of the AF Server itself.
But, as I mentioned before, if you
have gone to the trouble to configure more than one
AF Server, and you're pointing them to the same
AF Data...or to the same SQL Server Database,
then that's something that is entirely
do-able and we'll support during an AF Upgrade.
And again, the mechanism for that would be
you know, again, I have multiple copies of this
AF Server. Each one of these
multiple copies would be pointing to the
same Database in SQL Server.
And again, that's something that you can easily
do during the installation. If you take a look at
our Installation Section, you'll see that that is
a completely legitimate Option. We've got different AF
Servers all pointing to this same SQL Server
instance. That means they're sharing that
PI F -- PIFD Database in SQL Server.
Now this is typically done, or when
this is typically done, you know, this means what you're,
what you're essentially getting from this is a lot more
capacity for responding to Client Requests.
So, if you've got some kind of a layer here of Network
Load Balancing such that,
you know, as, as one of these becomes unavailable,
we immediately shift over, we redirect to others,
then that's entirely,
you know, a supported functionality.
And then, of course, another benefit of
sharing the load among these different AF Servers is
if this is down because it's being Upgraded, then,
you know, as soon as we finish upgrading it, we can move on and Upgrade this one,
Upgrade this one as we do that Rolling Upgrade.
As the others stay on line and available, we're able
to do the Reads and Writes to satisfy User Requests.
In the case of the Mirrored Environment, there
is no special, you know, shared to Disk Array required,
like there is for the Clustered Environment. And again, for more
information on that you'd have to check with Microsoft. And the
requirement for SQL Server here is going to be it's going to require
the Standard Edition to do Mirroring. So, again,
SQL Server Express is not supported in that
Configuration. Now, I'd like to make one last point
about this Option that I've described here in which
we've got multiple AF Servers pointing to the same
copy of the SQL Server, you know, the AF
SQL Server Database. And that is that if you
look at this Table, look at this Option right here, this
Read Write Access During AF Upgrade.
We write No for
all of these Configurations, except, as I
said, the qualified No that if you are
implementing multiple AF Servers, these No's
right here turns into Y's for yeses. So,
you know, I kind of pointed these out parenthetically
that this is an Option. But, as, as it ends up this is
the best Option, if what you're looking for is
100% availability without
any chance of having a time in which
the Reads and Writes are not being done.
Now, one final note. These first two things that we've
discussed were all things that were supported through, essentially through Microsoft's
technology. Now, in our
next video we're going to be taking a look at the AF Collective
that -- where we're using both our technology
and also piggybacking on some of what Microsoft's done.