WEBVTT

00:00:00.000 --> 00:00:02.745
>> Big data clusters provide

00:00:02.745 --> 00:00:05.640
a way of keeping the cluster
reliable by enabling

00:00:05.640 --> 00:00:08.460
high availability for critical
components and Mihaela is

00:00:08.460 --> 00:00:12.120
here to tell us all about
it today on Data Exposed.

00:00:12.120 --> 00:00:23.400
[MUSIC]

00:00:23.400 --> 00:00:26.475
>> Hi, and welcome to another
episode of Data Exposed.

00:00:26.475 --> 00:00:30.480
I'm your host Jeroen and today
we have Mihaela with us to talk

00:00:30.480 --> 00:00:32.265
about big data clusters and then

00:00:32.265 --> 00:00:34.970
specifically the high
availability for them.

00:00:34.970 --> 00:00:37.655
So welcome back. This it must
be the third time I think.

00:00:37.655 --> 00:00:39.560
>> Yeah. Thank you. Thank
you for having me here.

00:00:39.560 --> 00:00:40.985
>> Yeah. You're becoming a pro.

00:00:40.985 --> 00:00:43.550
So most of the topics you talk

00:00:43.550 --> 00:00:46.445
about is big data clusters
and today is no different.

00:00:46.445 --> 00:00:48.345
But then high availability, right?

00:00:48.345 --> 00:00:50.780
>> Yeah. So there are
a lot of things to

00:00:50.780 --> 00:00:53.360
talk about when it comes
to high availability.

00:00:53.360 --> 00:00:54.155
>> Okay.

00:00:54.155 --> 00:00:57.590
>> We're going to go through some
of those aspects in this video.

00:00:57.590 --> 00:00:59.785
>> Okay. Cool. Now let's get started.

00:00:59.785 --> 00:01:05.745
>> So when we talk about data
especially and databases,

00:01:05.745 --> 00:01:07.800
we want to make sure that
data is persistence.

00:01:07.800 --> 00:01:09.110
So I just want to start with

00:01:09.110 --> 00:01:13.430
this high availability talk
with the storage recap.

00:01:13.430 --> 00:01:13.650
>> Okay.

00:01:13.650 --> 00:01:14.850
>> So different layers in

00:01:14.850 --> 00:01:17.840
the big data cluster have
different options for storage.

00:01:17.840 --> 00:01:20.180
Either you can do a local storage or

00:01:20.180 --> 00:01:23.150
remote and we made it as granular as

00:01:23.150 --> 00:01:25.970
you can opt in for local or remote

00:01:25.970 --> 00:01:28.895
depending if you want to
store data, or the logs.

00:01:28.895 --> 00:01:33.680
So logs you don't want
necessarily to make it redundant

00:01:33.680 --> 00:01:36.865
because you might need it for

00:01:36.865 --> 00:01:40.930
troubleshooting but then you
don't want to keep them forever.

00:01:41.090 --> 00:01:42.190
>> [inaudible].

00:01:42.190 --> 00:01:44.840
>> Exactly. So when
we talk about logs is

00:01:44.840 --> 00:01:48.140
mostly you want to keep
them on a local storage

00:01:48.140 --> 00:01:52.355
especially because we were talking
in the last video that we have

00:01:52.355 --> 00:01:54.590
components in the clusters that are

00:01:54.590 --> 00:01:57.410
collecting those logs and are
starting them in an elastic search.

00:01:57.410 --> 00:02:01.615
So you already have some
dependency on that aspect.

00:02:01.615 --> 00:02:04.410
When it comes to data,
various components

00:02:04.410 --> 00:02:08.270
have different requirements
depending on how

00:02:08.270 --> 00:02:10.730
a mission critical are and if there's

00:02:10.730 --> 00:02:15.140
any user data that is stored
in for data for example,

00:02:15.140 --> 00:02:20.030
SQL Server master or storage
pool like HDFS data is kept.

00:02:20.030 --> 00:02:22.955
You do want to maintain
redundancy for that.

00:02:22.955 --> 00:02:28.445
But Compute pool or Spark,

00:02:28.445 --> 00:02:30.695
there is no state.

00:02:30.695 --> 00:02:33.380
It is just computes.
So there's no point

00:02:33.380 --> 00:02:36.560
to add additional
redundancy to the storage.

00:02:36.560 --> 00:02:38.225
>> Exactly. So you can choose local.

00:02:38.225 --> 00:02:39.470
>> So we're talking here about

00:02:39.470 --> 00:02:42.260
different options that
you have to ensure

00:02:42.260 --> 00:02:44.810
the reliability of those services

00:02:44.810 --> 00:02:46.400
when it comes to data persistence.

00:02:46.400 --> 00:02:47.620
>> Okay.

00:02:47.620 --> 00:02:51.575
>> That's where we continue
with the HA options, right?

00:02:51.575 --> 00:02:55.985
So for SQL Server master if your
store your data locally,

00:02:55.985 --> 00:02:57.725
you must ensure that you're adding

00:02:57.725 --> 00:02:59.675
some additional redundancy to that

00:02:59.675 --> 00:03:01.340
with Availability Groups
and we are going to

00:03:01.340 --> 00:03:04.160
see shortly how's that enabled.

00:03:04.160 --> 00:03:05.990
When it comes to Data pool,

00:03:05.990 --> 00:03:13.970
you use PVs in Kubernetes to
ensure that data is persistent.

00:03:13.970 --> 00:03:15.350
>> So just PVs, right?

00:03:15.350 --> 00:03:16.505
There's lot of acronyms here.

00:03:16.505 --> 00:03:17.240
>> Yeah.

00:03:17.240 --> 00:03:21.110
>> AG, PV, HA, everything? PV is.

00:03:21.110 --> 00:03:25.175
>> PVs it's
a Kubernetes concept

00:03:25.175 --> 00:03:28.250
that abstracts the storage layer of

00:03:28.250 --> 00:03:32.090
Kubernetes and ensures if you're
using persistent volumes.

00:03:32.090 --> 00:03:35.270
So the notion is data persistence.

00:03:35.270 --> 00:03:37.010
So if you're using
persistent volume is it

00:03:37.010 --> 00:03:38.840
means that Kubernetes ensures that

00:03:38.840 --> 00:03:42.440
data is persisted on that storage.

00:03:42.440 --> 00:03:43.580
>> Okay. Got it.

00:03:43.580 --> 00:03:46.655
>> Again, that is no need to ensure

00:03:46.655 --> 00:03:49.435
high availability for compute
because it's stateless.

00:03:49.435 --> 00:03:52.110
We have critical components

00:03:52.110 --> 00:03:53.870
in the Hadoop Stack
right when it comes to

00:03:53.870 --> 00:03:56.600
HDFS NameNode and some Spark shared

00:03:56.600 --> 00:04:00.545
services that you need to
enable High Availability for,

00:04:00.545 --> 00:04:03.020
and very important I
want to highlight here

00:04:03.020 --> 00:04:09.000
the Control Service that you must
have not only persistent volume,

00:04:09.000 --> 00:04:11.490
you need to add some
redundancy to that story.

00:04:11.490 --> 00:04:14.135
So it has to be some
remote redundant storage.

00:04:14.135 --> 00:04:16.940
Don't keep your Control metadata

00:04:16.940 --> 00:04:21.410
locally because if that
node is last here,

00:04:21.410 --> 00:04:23.960
pretty much entire cluster is
not in a very good state.

00:04:23.960 --> 00:04:28.130
>> Okay. So Control will have
PVs on a remote storage?

00:04:28.130 --> 00:04:29.270
>> Remote and redundant.

00:04:29.270 --> 00:04:31.100
So you have to make
sure that they add

00:04:31.100 --> 00:04:33.005
some redundancy to that layer.

00:04:33.005 --> 00:04:34.710
>> Okay. Noted.

00:04:34.710 --> 00:04:37.290
>> So now let's see
what that means for

00:04:37.290 --> 00:04:41.085
SQL Server master and
enabling AG's for that.

00:04:41.085 --> 00:04:45.095
So this is a schema or

00:04:45.095 --> 00:04:50.045
how the layout of various services
that form the SQL Server,

00:04:50.045 --> 00:04:55.190
high availability layer
for SQL Server master.

00:04:55.190 --> 00:04:57.020
Again, we have a primary which

00:04:57.020 --> 00:05:00.785
is at least two secondaries
right synchronous,

00:05:00.785 --> 00:05:04.670
and we built components that

00:05:04.670 --> 00:05:08.985
are ensuring that there
is automatic monitoring,

00:05:08.985 --> 00:05:11.370
automatic fail-over
and orchestration.

00:05:11.370 --> 00:05:12.960
If something happens with a primary,

00:05:12.960 --> 00:05:17.675
it happens automatically, there
is no need to do anything.

00:05:17.675 --> 00:05:20.330
One thing that I want
to highlight here is

00:05:20.330 --> 00:05:23.870
that for big data cluster
only at this time,

00:05:23.870 --> 00:05:27.755
we also enable what we call a
Contained Availability Group,

00:05:27.755 --> 00:05:30.920
which means that now objects that

00:05:30.920 --> 00:05:33.920
you store in master for example like

00:05:33.920 --> 00:05:40.190
logins are also replicated
to the secondaries, right?

00:05:40.190 --> 00:05:40.380
>> Okay.

00:05:40.380 --> 00:05:43.880
>> So until there is no, like this is
a long outstanding ask from

00:05:43.880 --> 00:05:45.770
our customers to make
sure that logins

00:05:45.770 --> 00:05:47.930
are also replicated otherwise,

00:05:47.930 --> 00:05:49.610
there are a lot of orchestration and

00:05:49.610 --> 00:05:51.935
manual replication they had to do.

00:05:51.935 --> 00:05:55.290
Right now automatically
everything is taken care of.

00:05:55.290 --> 00:05:57.060
So from deployment, from adding

00:05:57.060 --> 00:05:59.130
databases to the availability groups,

00:05:59.130 --> 00:06:05.330
to adding this master replicated
database to the availability groups.

00:06:05.330 --> 00:06:08.555
So there is little if none

00:06:08.555 --> 00:06:13.130
almost operational management of

00:06:13.130 --> 00:06:16.620
the availability group.
That's pretty awesome.

00:06:16.620 --> 00:06:18.660
>> Yeah. That's really
awesome. I was going to say.

00:06:18.660 --> 00:06:21.230
So but you mentioned
availability groups now, right?

00:06:21.230 --> 00:06:21.390
>> Yeah.

00:06:21.390 --> 00:06:24.330
>> Is that the regular?

00:06:24.330 --> 00:06:27.200
>> Yeah. It is exactly
the same feature that we

00:06:27.200 --> 00:06:30.050
all know from SQL Server 2012, right?

00:06:30.050 --> 00:06:30.605
>> Yeah.

00:06:30.605 --> 00:06:33.440
>> One thing that
it's very important.

00:06:33.440 --> 00:06:35.960
There is no other cluster technology

00:06:35.960 --> 00:06:39.365
that you're going to have to
deploy or integrate with.

00:06:39.365 --> 00:06:41.445
Its everything taken care of,

00:06:41.445 --> 00:06:44.590
the services that are deploying
with the HA supervisor,

00:06:44.590 --> 00:06:45.730
the operator and of

00:06:45.730 --> 00:06:49.840
course tightly integrating with
Kubernetes in this case.

00:06:49.840 --> 00:06:52.560
So we are taking advantage
of these platforms.

00:06:52.560 --> 00:06:54.100
>> So no more cluster technology.

00:06:54.100 --> 00:06:56.650
So this is great for the master instance.

00:06:56.650 --> 00:07:00.510
So now I trust the master
instance is fine.

00:07:00.510 --> 00:07:02.250
But there's more in a BDC, right?

00:07:02.250 --> 00:07:03.965
We're not only doing a SQL Server,

00:07:03.965 --> 00:07:05.980
we're doing Hadoop
related stuff.

00:07:05.980 --> 00:07:07.510
So tell me.

00:07:07.510 --> 00:07:10.230
>> So let's look at what we're
doing for Hadoop, for HDFS.

00:07:10.230 --> 00:07:13.690
So HDFS NameNode must also be in

00:07:13.690 --> 00:07:16.540
a highly available configuration
because that's critical

00:07:16.540 --> 00:07:20.035
for the Hadoop Stack,

00:07:20.035 --> 00:07:23.205
and what we're seeing that the
customer is telling us, ''Oh,

00:07:23.205 --> 00:07:26.395
I want replication for NameNode'',

00:07:26.395 --> 00:07:28.640
We're also deploying Zookeeper which

00:07:28.640 --> 00:07:31.430
is an open source cluster technology.

00:07:31.430 --> 00:07:35.750
That's the component that is going
to take care of coordinating

00:07:35.750 --> 00:07:39.800
the monitoring and the fail-over if

00:07:39.800 --> 00:07:44.970
needed of the NameNode
to a standby secondary.

00:07:44.970 --> 00:07:45.070
>> Okay.

00:07:45.070 --> 00:07:47.330
>> So deploying an additional replica

00:07:47.330 --> 00:07:49.985
and Zookeeper is taking care
of the orchestration aspect.

00:07:49.985 --> 00:07:50.675
>> Okay.

00:07:50.675 --> 00:07:55.235
>> In the same time
it's also involved in

00:07:55.235 --> 00:07:58.580
maintaining high availability for

00:07:58.580 --> 00:08:03.679
some Spark shared components
like Yarn Resource Manager,

00:08:03.679 --> 00:08:07.520
and in that sense for
Spark we also deploy

00:08:07.520 --> 00:08:12.200
multiple replicas for services
like Spark History, Job History.

00:08:12.200 --> 00:08:15.515
So to make sure that if something is

00:08:15.515 --> 00:08:19.900
going on in OneNote that
these services are hosted,

00:08:19.900 --> 00:08:23.495
The role would be picked
up by the additional replicas.

00:08:23.495 --> 00:08:24.790
>> Cool.

00:08:24.790 --> 00:08:28.490
>> So let's see how easy it is to

00:08:28.490 --> 00:08:32.570
configure the high availability
for the various components.

00:08:32.570 --> 00:08:33.530
>> Tell me it's easy.

00:08:33.530 --> 00:08:35.510
>> It is super easy.

00:08:35.510 --> 00:08:38.280
>> Cool. I like easy.

00:08:38.470 --> 00:08:42.740
>> We talked last time about how
to configure your deployments.

00:08:42.740 --> 00:08:43.820
>> Yes. I remember that.

00:08:43.820 --> 00:08:47.270
>> There is the cluster
configuration files

00:08:47.270 --> 00:08:49.675
or deployment templates
that you have,

00:08:49.675 --> 00:08:52.280
and remember we're
talking earlier about

00:08:52.280 --> 00:08:55.700
the Spark shared components.

00:08:55.700 --> 00:08:56.210
>> Yeah.

00:08:56.210 --> 00:08:59.975
>> I just say I just want two
replicas of them and that's it.

00:08:59.975 --> 00:09:02.060
We take care of
picking up from there.

00:09:02.060 --> 00:09:03.020
>> Is that all?

00:09:03.020 --> 00:09:04.610
>> The Zookeeper. So again,

00:09:04.610 --> 00:09:08.450
we have to go through all the
components that we went through.

00:09:08.450 --> 00:09:12.980
Zookeeper we're going to need
three replicas to ensure quorum.

00:09:12.980 --> 00:09:16.145
Then we also mentioned master,

00:09:16.145 --> 00:09:19.465
SQL Server master instance
and what do I do here?

00:09:19.465 --> 00:09:22.755
I'd just say that I
want three replicas,

00:09:22.755 --> 00:09:26.930
and because SQL Server
availability groups

00:09:26.930 --> 00:09:28.985
also enables readable secondaries,

00:09:28.985 --> 00:09:31.640
we will give you the option to

00:09:31.640 --> 00:09:36.440
deploy a service that
is exposing an endpoint

00:09:36.440 --> 00:09:39.920
to do read-only workloads

00:09:39.920 --> 00:09:41.780
from almost secondary
and you just have to

00:09:41.780 --> 00:09:44.015
specify the port here in this case.

00:09:44.015 --> 00:09:47.900
>> Right. So you do a high
availability and as part of that,

00:09:47.900 --> 00:09:49.980
you could also do the
read-only offloading.

00:09:49.980 --> 00:09:51.365
>> Exactly. Yeah.

00:09:51.365 --> 00:09:54.290
>> Cool. Is that how you read this
just as one line and everything works?

00:09:54.290 --> 00:09:57.470
>> Yeah. You just specify
how many replicas you

00:09:57.470 --> 00:10:02.480
don't worry about orchestrating,

00:10:02.480 --> 00:10:05.900
deploying additional
components like when you tell

00:10:05.900 --> 00:10:09.545
us that I want three replicas
for SQL Server master,

00:10:09.545 --> 00:10:10.820
we deploy the operator,

00:10:10.820 --> 00:10:12.260
we deployed the supervisor that is

00:10:12.260 --> 00:10:14.030
doing the monitoring
and everything else.

00:10:14.030 --> 00:10:17.180
So everything is behind
the scenes and there

00:10:17.180 --> 00:10:21.380
is minimal orchestration
for setting things up.

00:10:21.380 --> 00:10:23.840
For folks that are
very familiar with how

00:10:23.840 --> 00:10:27.905
to configure an availability
groups I think it's

00:10:27.905 --> 00:10:32.090
at least four or five
T-SQL statements

00:10:32.090 --> 00:10:34.970
plus prepping endpoints
and things like that.

00:10:34.970 --> 00:10:37.355
So this pretty awesome.

00:10:37.355 --> 00:10:39.830
It's taking that load from you to

00:10:39.830 --> 00:10:42.415
focus on actually running workloads
on the big data cluster

00:10:42.415 --> 00:10:44.940
>> Right. It doesn't get more
simple than this, right?

00:10:44.940 --> 00:10:45.420
>> It is.

00:10:45.420 --> 00:10:48.350
>> One line and then of course if
the master instance if you want

00:10:48.350 --> 00:10:52.430
more lines for read only but
yeah that's really impressive.

00:10:52.430 --> 00:10:54.740
Cool. So where can I
find more about this?

00:10:54.740 --> 00:10:56.385
How do I get started?

00:10:56.385 --> 00:11:00.920
>> So definitely I'll show you

00:11:00.920 --> 00:11:03.915
exactly some links
that you can leverage

00:11:03.915 --> 00:11:07.140
for the deployment,
for the configuration.

00:11:07.140 --> 00:11:11.749
So you can find hear more about
it in our documentation platform

00:11:11.749 --> 00:11:14.000
but we also have a lot
of samples out there

00:11:14.000 --> 00:11:16.460
on how to configure things,

00:11:16.460 --> 00:11:18.500
how to run workloads,

00:11:18.500 --> 00:11:21.380
and everything you
can go ahead to use

00:11:21.380 --> 00:11:24.350
this links and leverage them for
what do whatever you want to do.

00:11:24.350 --> 00:11:25.490
in your big data clusters.

00:11:25.490 --> 00:11:28.550
>> Cool. Well, thanks again for
sharing and talking though this.

00:11:28.550 --> 00:11:30.260
This is a very impressive.

00:11:30.260 --> 00:11:32.555
I like the easiness of creating this.

00:11:32.555 --> 00:11:32.760
>> Yeah.

00:11:32.760 --> 00:11:34.700
>> This is clearly a lot of work went into this.

00:11:34.700 --> 00:11:36.695
>> Pretty awesome. Yes. Thank you.

00:11:36.695 --> 00:11:39.410
>> Well, thanks. Thank
you for watching.

00:11:39.410 --> 00:11:41.525
Please like, subscribe,
leave a comment,

00:11:41.525 --> 00:11:43.830
and hope to see you
next time. Thanks.

00:11:43.830 --> 00:11:55.690
[MUSIC]