WEBVTT

00:00:00.000 --> 00:00:02.745
• 大資料集群提供

00:00:02.745 --> 00:00:05.640
保持群集的方法
通過啟用

00:00:05.640 --> 00:00:08.460
高可用性，適用于關鍵
元件和米哈伊拉是

00:00:08.460 --> 00:00:12.120
在這裡告訴我們所有關于
它今天在資料暴露。

00:00:12.120 --> 00:00:23.400
[音樂]

00:00:23.400 --> 00:00:26.475
• 嗨，歡迎來到另一個
一集資料暴露。

00:00:26.475 --> 00:00:30.480
我是你的東道主傑琳，今天
我們有米哈伊拉和我們談談

00:00:30.480 --> 00:00:32.265
關於大資料集群，然後

00:00:32.265 --> 00:00:34.970
特別是高
可用性。

00:00:34.970 --> 00:00:37.655
所以歡迎回來。這是必須的
是第四次我想。

00:00:37.655 --> 00:00:39.560
* 是的。謝謝。謝謝
你把我留在這裡

00:00:39.560 --> 00:00:40.985
* 是的。你正在成為一個探測器。

00:00:40.985 --> 00:00:43.550
所以大多數你談論的話題

00:00:43.550 --> 00:00:46.445
關於大資料集群
今天也不例外。

00:00:46.445 --> 00:00:48.345
但是高可用性，對嗎？

00:00:48.345 --> 00:00:50.780
* 是的。所以有
很多事情

00:00:50.780 --> 00:00:53.360
談論它何時到來
高可用性。

00:00:53.360 --> 00:00:54.155
"好的。

00:00:54.155 --> 00:00:57.590
• 我們將經歷一些
這些方面在本視頻中。

00:00:57.590 --> 00:00:59.785
"好的。酷。現在讓我們開始吧。

00:00:59.785 --> 00:01:05.745
[ ] 所以當我們談論資料時
特別是和資料庫，

00:01:05.745 --> 00:01:07.800
我們想確保
資料是持久性。

00:01:07.800 --> 00:01:09.110
所以我只想從

00:01:09.110 --> 00:01:13.430
這種高可用性的談話
與存儲回顧。

00:01:13.430 --> 00:01:13.650
"好的。

00:01:13.650 --> 00:01:14.850
• 使中的圖層不同

00:01:14.850 --> 00:01:17.840
大資料群集具有
不同的存儲選項。

00:01:17.840 --> 00:01:20.180
您可以執行本機存放區，或者

00:01:20.180 --> 00:01:23.150
遠端，我們把它作為細微性

00:01:23.150 --> 00:01:25.970
您可以選擇本地或遠端

00:01:25.970 --> 00:01:28.895
取決於如果你想
存儲資料或日誌。

00:01:28.895 --> 00:01:33.680
所以，你不想要的日誌
必然使其冗余

00:01:33.680 --> 00:01:36.865
因為你可能需要它

00:01:36.865 --> 00:01:40.930
故障排除，但隨後您
不想永遠留著它們

00:01:41.090 --> 00:01:42.190
[ 聽不到]。

00:01:42.190 --> 00:01:44.840
* 確切地說。所以當
我們談論的日誌是

00:01:44.840 --> 00:01:48.140
主要是你想保持
他們在本機存放區

00:01:48.140 --> 00:01:52.355
特別是因為我們在談論
在最後一個視頻中，我們有

00:01:52.355 --> 00:01:54.590
群集中的元件

00:01:54.590 --> 00:01:57.410
收集這些日誌，並
在彈性搜索中啟動它們。

00:01:57.410 --> 00:02:01.615
所以你已經有了一些
依賴這一方面。

00:02:01.615 --> 00:02:04.410
當涉及到資料時，
各種元件

00:02:04.410 --> 00:02:08.270
有不同的要求
取決於如何

00:02:08.270 --> 00:02:10.730
任務關鍵是，如果有

00:02:10.730 --> 00:02:15.140
存儲的任何使用者資料
例如，對於資料，

00:02:15.140 --> 00:02:20.030
SQL 伺服器主機或存儲
池，如 HDFS 資料被保留。

00:02:20.030 --> 00:02:22.955
您確實希望維護
冗余。

00:02:22.955 --> 00:02:28.445
但計算池或火花，

00:02:28.445 --> 00:02:30.695
沒有狀態。

00:02:30.695 --> 00:02:33.380
它只是計算。
所以沒有意義

00:02:33.380 --> 00:02:36.560
以添加其他
冗余到存儲。

00:02:36.560 --> 00:02:38.225
* 確切地說。所以，你可以選擇本地。

00:02:38.225 --> 00:02:39.470
• 因此，我們在這裡討論的

00:02:39.470 --> 00:02:42.260
不同的選項，
你必須確保

00:02:42.260 --> 00:02:44.810
這些服務的可靠性

00:02:44.810 --> 00:02:46.400
當涉及到資料持久性時。

00:02:46.400 --> 00:02:47.620
"好的。

00:02:47.620 --> 00:02:51.575
• 這就是我們繼續
與HA選項，對不對？

00:02:51.575 --> 00:02:55.985
因此，對於 SQL Server 主機，如果
在本地資料中的故事，

00:02:55.985 --> 00:02:57.725
你必須確保你添加

00:02:57.725 --> 00:02:59.675
一些額外的冗余，

00:02:59.675 --> 00:03:01.340
與可用性組
我們要

00:03:01.340 --> 00:03:04.160
稍後查看它是如何啟用的。

00:03:04.160 --> 00:03:05.990
當涉及到資料池時，

00:03:05.990 --> 00:03:13.970
在組合器中使用 PV
確保資料是持久性的。

00:03:13.970 --> 00:03:15.350
只是PV，對吧？

00:03:15.350 --> 00:03:16.505
這裡有很多首字母縮寫詞。

00:03:16.505 --> 00:03:17.240
* 是的。

00:03:17.240 --> 00:03:21.110
• 例如 PV，HA，所有光伏都是？

00:03:21.110 --> 00:03:25.175
* 建議PV
A 庫貝內特斯概念

00:03:25.175 --> 00:03:28.250
抽象存儲層

00:03:28.250 --> 00:03:32.090
Kubernetes，並確保您是否
使用持久卷。

00:03:32.090 --> 00:03:35.270
因此，概念是資料持久性。

00:03:35.270 --> 00:03:37.010
所以，如果你使用
持久卷是它

00:03:37.010 --> 00:03:38.840
意味著庫貝內特斯確保

00:03:38.840 --> 00:03:42.440
資料將保留到該存儲上。

00:03:42.440 --> 00:03:43.580
"好的。明白了。

00:03:43.580 --> 00:03:46.655
• 再次，這是沒有必要確保

00:03:46.655 --> 00:03:49.435
高計算可用性
因為它是無國籍的

00:03:49.435 --> 00:03:52.110
它有關鍵元件

00:03:52.110 --> 00:03:53.870
在 Hadoop 堆疊中
正確的，當它涉及到

00:03:53.870 --> 00:03:56.600
HDFS 名稱節點和一些火花共用

00:03:56.600 --> 00:04:00.545
您需要的服務
啟用高可用性，

00:04:00.545 --> 00:04:03.020
和非常重要的我
想在這裡突出顯示

00:04:03.020 --> 00:04:09.000
您必須的控制服務
不僅具有持久性的體積，

00:04:09.000 --> 00:04:11.490
你需要添加一些
冗余的故事。

00:04:11.490 --> 00:04:14.135
因此，它必須是一些
遠端冗余存儲。

00:04:14.135 --> 00:04:16.940
不要保持你的控制[聽不見]

00:04:16.940 --> 00:04:21.410
本地，因為如果
節點是最後一個在這裡，

00:04:21.410 --> 00:04:23.960
幾乎整個集群是
不在一個非常約束。

00:04:23.960 --> 00:04:28.130
"好的。因此，控制確實有
遠端存放上的 PV？

00:04:28.130 --> 00:04:29.270
• 遠端和冗余。

00:04:29.270 --> 00:04:31.100
所以，你必須使
確保他們添加

00:04:31.100 --> 00:04:33.005
該層有一些冗余。

00:04:33.005 --> 00:04:34.710
"好的。指出。

00:04:34.710 --> 00:04:37.290
[ ] 現在讓我們看看
這意味著什麼

00:04:37.290 --> 00:04:41.085
SQL 伺服器主機和
啟用 AG 的。

00:04:41.085 --> 00:04:45.095
因此，這是一個架構或

00:04:45.095 --> 00:04:50.045
各種服務的佈局
形成 SQL 伺服器，

00:04:50.045 --> 00:04:55.190
高可用性層
SQL Server 主機。

00:04:55.190 --> 00:04:57.020
同樣，我們有一個主

00:04:57.020 --> 00:05:00.785
至少兩個次要資料庫
右同步，

00:05:00.785 --> 00:05:04.670
我們構建了元件，

00:05:04.670 --> 00:05:08.985
正在確保有
是自動監控，

00:05:08.985 --> 00:05:11.370
自動容錯移轉
和編排。

00:05:11.370 --> 00:05:12.960
如果主資料庫發生某些情況，

00:05:12.960 --> 00:05:17.675
它會自動發生，有
不需要做任何事情。

00:05:17.675 --> 00:05:20.330
一件事，我想要
要突出顯示的是

00:05:20.330 --> 00:05:23.870
對於大資料群集
只在這個時候

00:05:23.870 --> 00:05:27.755
我們還啟用我們稱之為
包含可用性組，

00:05:27.755 --> 00:05:30.920
這意味著，現在的物件，

00:05:30.920 --> 00:05:33.920
您存儲在主，例如像

00:05:33.920 --> 00:05:40.190
登錄也複製
到二人，對不對？

00:05:40.190 --> 00:05:40.380
"好的。

00:05:40.380 --> 00:05:43.880
* 所以，直到現在這是
沿著發送我們從

00:05:43.880 --> 00:05:45.770
我們的客戶使
確保登錄

00:05:45.770 --> 00:05:47.930
也複製否則，

00:05:47.930 --> 00:05:49.610
有很多的指控和

00:05:49.610 --> 00:05:51.935
手動複製，他們必須做。

00:05:51.935 --> 00:05:55.290
現在自動
一切都被照顧好。

00:05:55.290 --> 00:05:57.060
因此，從部署，從添加

00:05:57.060 --> 00:05:59.130
資料庫到可用性組，

00:05:59.130 --> 00:06:05.330
添加複製的主機
資料庫可用性組。

00:06:05.330 --> 00:06:08.555
所以沒有什麼，如果沒有

00:06:08.555 --> 00:06:13.130
在運營管理中

00:06:13.130 --> 00:06:16.620
可用性組。
太棒了

00:06:16.620 --> 00:06:18.660
* 是的。那真是
棒。我正想說

00:06:18.660 --> 00:06:21.230
所以你提到
可用性組，對不對？

00:06:21.230 --> 00:06:21.390
* 是的。

00:06:21.390 --> 00:06:24.330
* 是常規的嗎？

00:06:24.330 --> 00:06:27.200
* 是的。它正是
相同的功能，我們

00:06:27.200 --> 00:06:30.050
所有人都知道從SQL Server 2012，對不對？

00:06:30.050 --> 00:06:30.605
* 是的。

00:06:30.605 --> 00:06:33.440
• 有一件事
這很重要。

00:06:33.440 --> 00:06:35.960
沒有其他群集技術

00:06:35.960 --> 00:06:39.365
你將不得不
部署或集成。

00:06:39.365 --> 00:06:41.445
一切都被照顧好

00:06:41.445 --> 00:06:44.590
正在部署的服務
與醫管局主管，

00:06:44.590 --> 00:06:45.730
運算子和

00:06:45.730 --> 00:06:49.840
課程緊密集成
庫伯內特斯在寫這個案子。

00:06:49.840 --> 00:06:52.560
因此，我們正在利用
這些平臺。

00:06:52.560 --> 00:06:54.100
• 因此，無需再使用群集技術。

00:06:54.100 --> 00:06:56.650
因此，這是偉大的掌握。

00:06:56.650 --> 00:07:00.510
所以現在我相信主人
實例正常。

00:07:00.510 --> 00:07:02.250
但BDC還有更多，對吧？

00:07:02.250 --> 00:07:03.965
我們不僅做 SQL 伺服器，

00:07:03.965 --> 00:07:05.980
我們正在做[聽不見]
相關的東西。

00:07:05.980 --> 00:07:07.510
告訴我吧

00:07:07.510 --> 00:07:10.230
• 讓我們來看看我們是什麼
做哈多普，為HDFS。

00:07:10.230 --> 00:07:13.690
因此，HDFS 名稱節點也必須在

00:07:13.690 --> 00:07:16.540
高度可用的配置
因為那很關鍵

00:07:16.540 --> 00:07:20.035
對於Hadoop堆疊，

00:07:20.035 --> 00:07:23.205
和我們看到的，
顧客告訴我們'哦，

00:07:23.205 --> 00:07:26.395
我想複製名稱節點'，

00:07:26.395 --> 00:07:28.640
也將部署動物園管理員

00:07:28.640 --> 00:07:31.430
是一種開源集群技術。

00:07:31.430 --> 00:07:35.750
這就是將要發生的元件
負責協調

00:07:35.750 --> 00:07:39.800
監視和容錯移轉（如果

00:07:39.800 --> 00:07:44.970
需要的名稱節點
到備用次要資料庫。

00:07:44.970 --> 00:07:45.070
"好的。

00:07:45.070 --> 00:07:47.330
• 因此，部署其他副本

00:07:47.330 --> 00:07:49.985
和動物園管理員正在照顧
業務流程方面。

00:07:49.985 --> 00:07:50.675
"好的。

00:07:50.675 --> 00:07:55.235
* 在同一時間
它也涉及

00:07:55.235 --> 00:07:58.580
保持高可用性

00:07:58.580 --> 00:08:03.679
一些 Spark 共用元件
像紗線資源管理器，

00:08:03.679 --> 00:08:07.520
並在這個意義上
火花，我們也部署

00:08:07.520 --> 00:08:12.200
服務的多個副本
像火花歷史，工作歷史。

00:08:12.200 --> 00:08:15.515
所以，為了確保，如果有什麼是

00:08:15.515 --> 00:08:19.900
在 OneNote 中繼續
這些服務被託管，

00:08:19.900 --> 00:08:23.495
[聽不見的]將被挑選
或附加副本。

00:08:23.495 --> 00:08:24.790
• 冷卻。

00:08:24.790 --> 00:08:28.490
• 因此，讓我們看看這是多麼容易

00:08:28.490 --> 00:08:32.570
配置高可用性
用於各種元件。

00:08:32.570 --> 00:08:33.530
告訴我這很容易。

00:08:33.530 --> 00:08:35.510
• 超級簡單。

00:08:35.510 --> 00:08:38.280
• 冷卻。我喜歡輕鬆。

00:08:38.470 --> 00:08:42.740
上次我們談過
配置部署。

00:08:42.740 --> 00:08:43.820
* 是。我記得

00:08:43.820 --> 00:08:47.270
• 有群集
設定檔

00:08:47.270 --> 00:08:49.675
或部署範本
你有，

00:08:49.675 --> 00:08:52.280
記住我們
談論早些時候

00:08:52.280 --> 00:08:55.700
Spark 共用元件。

00:08:55.700 --> 00:08:56.210
* 是的。

00:08:56.210 --> 00:08:59.975
我只是說我只想要兩個
他們的複製品，這就是它。

00:08:59.975 --> 00:09:02.060
我們照顧
從那裡拿起。

00:09:02.060 --> 00:09:03.020
就是這些嗎？

00:09:03.020 --> 00:09:04.610
• 動物園管理員。所以，再次，

00:09:04.610 --> 00:09:08.450
我們必須通過所有
元件，我們經歷了。

00:09:08.450 --> 00:09:12.980
動物園管理員，我們需要
三個副本，以確保仲裁。

00:09:12.980 --> 00:09:16.145
然後我們也提到主人

00:09:16.145 --> 00:09:19.465
SQL 伺服器主實例
我在這裡做什麼？

00:09:19.465 --> 00:09:22.755
我只是說，我
想要三個副本

00:09:22.755 --> 00:09:26.930
因為 SQL 伺服器
可用性組

00:09:26.930 --> 00:09:28.985
還支援可讀的次要資料庫，

00:09:28.985 --> 00:09:31.640
會給你選擇

00:09:31.640 --> 00:09:36.440
部署一項服務，
正在公開終結點

00:09:36.440 --> 00:09:39.920
執行遠端工作負載

00:09:39.920 --> 00:09:41.780
從從從輔助
你只需要

00:09:41.780 --> 00:09:44.015
在這種情況下指定此處的埠。

00:09:44.015 --> 00:09:47.900
* 正確。所以你做了一個高
可用性，作為其中的一部分，

00:09:47.900 --> 00:09:49.980
您也可以做
唯讀，[聽不見]

00:09:49.980 --> 00:09:51.365
* 確切地說。是的。

00:09:51.365 --> 00:09:54.290
• 冷卻。你就是這樣讀的
就像一行[聽不見]？

00:09:54.290 --> 00:09:57.470
* 是的。您只指定
有多少副本

00:09:57.470 --> 00:10:02.480
不用擔心策劃

00:10:02.480 --> 00:10:05.900
部署其他
元件，如當你告訴

00:10:05.900 --> 00:10:09.545
我們，我想要三個副本
對於 SQL 伺服器主機，

00:10:09.545 --> 00:10:10.820
我們部署操作員，

00:10:10.820 --> 00:10:12.260
我們部署了主管，即

00:10:12.260 --> 00:10:14.030
做監控
和其他一切。

00:10:14.030 --> 00:10:17.180
所以一切都落後了
場景和

00:10:17.180 --> 00:10:21.380
是最小的業務流程
設置的東西。

00:10:21.380 --> 00:10:23.840
對於
非常熟悉如何

00:10:23.840 --> 00:10:27.905
配置可用性
團體，我認為這是

00:10:27.905 --> 00:10:32.090
至少四或五個
T-SQL 語句

00:10:32.090 --> 00:10:34.970
加上準備端點
和類似的東西。

00:10:34.970 --> 00:10:37.355
所以，這是刺耳的問。

00:10:37.355 --> 00:10:39.830
它從YouTube的負載

00:10:39.830 --> 00:10:42.415
專注于實際運行
大資料上的內容。

00:10:42.415 --> 00:10:44.940
* 正確。它沒有得到更多
比這更簡單，對吧？

00:10:44.940 --> 00:10:45.420
* 是。

00:10:45.420 --> 00:10:48.350
* 一行，然後當然，如果
主實例（如果需要）

00:10:48.350 --> 00:10:52.430
更多行用於唯讀，但
是的，那真是令人印象深刻。

00:10:52.430 --> 00:10:54.740
酷。那麼，我在哪裡可以
瞭解更多？

00:10:54.740 --> 00:10:56.385
如何開始？

00:10:56.385 --> 00:11:00.920
* 所以，我一定會告訴你

00:11:00.920 --> 00:11:03.915
正好一些連結
你可以利用

00:11:03.915 --> 00:11:07.140
進行部署，
配置。

00:11:07.140 --> 00:11:11.749
因此，您可以找到聽到更多關於
在我們的文檔平臺中

00:11:11.749 --> 00:11:14.000
但我們也有很多
樣品在那裡

00:11:14.000 --> 00:11:16.460
有關如何配置內容。

00:11:16.460 --> 00:11:18.500
如何運行工作負載，

00:11:18.500 --> 00:11:21.380
和你一切
可以繼續前進使用

00:11:21.380 --> 00:11:24.350
此連結，並利用他們
無論你想做什麼

00:11:24.350 --> 00:11:25.490
你將成為我們的集群。

00:11:25.490 --> 00:11:28.550
• 冷卻。再次感謝
分享和交談，雖然這。

00:11:28.550 --> 00:11:30.260
這非常令人印象深刻。

00:11:30.260 --> 00:11:32.555
我喜歡創造這個的輕鬆。

00:11:32.555 --> 00:11:32.760
* 是的。

00:11:32.760 --> 00:11:34.700
• 這顯然是一項工作。

00:11:34.700 --> 00:11:36.695
* 相當真棒。是的。謝謝。

00:11:36.695 --> 00:11:39.410
"謝謝謝謝
你看。

00:11:39.410 --> 00:11:41.525
請喜歡，訂閱，
留下評論

00:11:41.525 --> 00:11:43.830
希望見到你
下次。謝謝。

00:11:43.830 --> 00:11:55.690
[音樂]