WEBVTT

00:00:00.000 --> 00:00:10.560
(Музыка).

00:00:10.560 --> 00:00:11.895
Привет, меня зовут Ахмед Банерджи.

00:00:11.895 --> 00:00:14.520
Я менеджер группы программ с
группа продуктов сервера S'L.

00:00:14.520 --> 00:00:17.970
Я несу ответственность за
движок базы данных для сервера S'L.

00:00:17.970 --> 00:00:19.110
Итак, в сегодняшнем видео,

00:00:19.110 --> 00:00:21.150
мы собираемся поговорить о
Высокий сервер S'L

00:00:21.150 --> 00:00:23.250
доступность и катастрофа
преимущества восстановления

00:00:23.250 --> 00:00:26.055
которые были введены
в ноябре 2019 года.

00:00:26.055 --> 00:00:29.910
Так что давайте выясним, как мы
на самом деле развертывание сервера S'L

00:00:29.910 --> 00:00:31.830
сегодня в высокой доступности

00:00:31.830 --> 00:00:33.780
и конфигурация аварийного восстановления.

00:00:33.780 --> 00:00:37.555
Итак, предположим, что у вас есть первичный
экземпляра сервера S'L.

00:00:37.555 --> 00:00:40.040
Основной экземпляр теперь может иметь,

00:00:40.040 --> 00:00:41.900
в зависимости от особенностя
что вы используете,

00:00:41.900 --> 00:00:45.080
Является ли это наличие
групп или журнал доставки,

00:00:45.080 --> 00:00:47.285
он может иметь несколько второстепенных.

00:00:47.285 --> 00:00:50.375
Если у вас высокий
решения для доступности

00:00:50.375 --> 00:00:52.580
как случаи кластера Fail-over,

00:00:52.580 --> 00:00:57.560
то это HA только решения
и у вас нет узла DR,

00:00:57.560 --> 00:01:00.935
Вы должны использовать другие
технологии для развертывания DR.

00:01:00.935 --> 00:01:06.335
Так что если у вас это с
Сервер S'L 2019 или ниже,

00:01:06.335 --> 00:01:07.790
и это было, скажем так,

00:01:07.790 --> 00:01:10.220
другой сервер S'L 2019 и ниже,

00:01:10.220 --> 00:01:13.045
и то же самое здесь.

00:01:13.045 --> 00:01:15.100
До первого ноября

00:01:15.100 --> 00:01:17.660
если у вас есть программное обеспечение и

00:01:17.660 --> 00:01:20.030
ваше предприятие соглашение дало

00:01:20.030 --> 00:01:22.205
вы Software Assurance возможности,

00:01:22.205 --> 00:01:25.739
Вы могли бы
лицензировать первичные,

00:01:25.739 --> 00:01:28.040
первая высокая доступность или

00:01:28.040 --> 00:01:30.755
DR реплики не будет
должны быть лицензированы,

00:01:30.755 --> 00:01:36.070
и следующая реплика DR будет
по-прежнему лицензированы.

00:01:36.070 --> 00:01:39.735
Начиная с сервера S'L 2019,

00:01:39.735 --> 00:01:43.270
и это относится ко всем старым
версии сервера S'L также,

00:01:43.270 --> 00:01:45.545
если у вас та же архитектура,

00:01:45.545 --> 00:01:47.930
если у вас есть первичные сейчас,

00:01:47.930 --> 00:01:49.550
Я просто нарисую это право

00:01:49.550 --> 00:01:52.580
выровнены так, что это
немного легче понять.

00:01:52.580 --> 00:01:54.530
У вас есть несколько второстепенных.

00:01:54.530 --> 00:01:56.240
Допустим, это используется для

00:01:56.240 --> 00:01:59.015
высокая доступность, и это
для аварийного восстановления,

00:01:59.015 --> 00:02:02.960
ваш основной будет ссылка, чтобы быть
лицензированы в соответствии с Software Assurance.

00:02:02.960 --> 00:02:05.825
Ваша первая реплика HA,

00:02:05.825 --> 00:02:08.540
который является синхронным
в природе и поддерживает

00:02:08.540 --> 00:02:11.660
автоматический сбой делает
не должны быть лицензированы,

00:02:11.660 --> 00:02:15.575
и катастрофа реплики также
не нужно лицензировать.

00:02:15.575 --> 00:02:17.795
Итак, давайте выясним, что
что на самом деле означает.

00:02:17.795 --> 00:02:26.720
Итак, предположим, что это было 32
ядер и у вас было 32 каждый,

00:02:26.720 --> 00:02:28.400
просто, чтобы сделать его проще.

00:02:28.400 --> 00:02:33.845
Таким образом, до ноября 2019 года

00:02:33.845 --> 00:02:36.860
Вам придется
лицензия на первичное,

00:02:36.860 --> 00:02:39.979
нет для первого вторичного,

00:02:39.979 --> 00:02:46.970
и еще 32 ядра
для следующего вторичного.

00:02:46.970 --> 00:02:50.490
Теперь, если у вас есть сервер S'L или

00:02:50.490 --> 00:02:52.385
любой релиз сервера S'L до тех пор, пока

00:02:52.385 --> 00:02:54.725
ядра покрыты
с помощью программного обеспечения,

00:02:54.725 --> 00:02:59.690
что вам действительно нужно лицензировать
для поста ноября во-первых,

00:02:59.690 --> 00:03:01.880
2019 год является основным,

00:03:01.880 --> 00:03:05.305
и до двух второстепенных,
это было бы бесплатно.

00:03:05.305 --> 00:03:07.605
Это означает,

00:03:07.605 --> 00:03:09.825
предположим, что у вас 32 ядра,

00:03:09.825 --> 00:03:12.920
ваше лицензирование будет выглядеть следующим образом.

00:03:12.920 --> 00:03:16.370
Теперь, как я на самом деле настроить это?

00:03:16.370 --> 00:03:20.615
Является первым предварительным условием, вам нужно
иметь программное обеспечение.

00:03:20.615 --> 00:03:27.900
Второе условие, вы можете
лицензировать ядра на первичном.

00:03:27.900 --> 00:03:31.580
Количество ядер на
вторичное должно

00:03:31.580 --> 00:03:38.430
быть меньше, чем или равна
количество первичных ядер.

00:03:39.890 --> 00:03:44.405
Например, если вы
было более 32 здесь,

00:03:44.405 --> 00:03:46.115
то льгота не будет применяться.

00:03:46.115 --> 00:03:49.520
Таким образом, по существу, для каждого
ядро, которое вы лицензии

00:03:49.520 --> 00:03:56.330
для сообщений sL Server в ноябре
и у вас есть гарантия программного обеспечения,

00:03:56.330 --> 00:04:00.485
вы получаете одно ядро HA,

00:04:00.485 --> 00:04:04.350
который является синхронным, одним ядром DR.

00:04:04.350 --> 00:04:06.080
В дополнение к этому,

00:04:06.080 --> 00:04:13.415
Вы также получите еще один DR
ядро, работая на M M Azure.

00:04:13.415 --> 00:04:15.110
Так что если вы работаете на

00:04:15.110 --> 00:04:16.865
виртуальная машина Azure, и вы

00:04:16.865 --> 00:04:19.160
используя это в качестве
место аварийного восстановления,

00:04:19.160 --> 00:04:21.215
Вы также получите, что бесплатно.

00:04:21.215 --> 00:04:23.570
Таким образом, в этой архитектуре,

00:04:23.570 --> 00:04:26.540
скажем, до ноября,

00:04:26.540 --> 00:04:27.680
вы добавили вторичное,

00:04:27.680 --> 00:04:30.460
но это было на Azure VM.

00:04:30.460 --> 00:04:36.220
Вы заплатили бы еще 32 ядра
при условии, что это 32 виртуальных ядер.

00:04:36.220 --> 00:04:39.545
В этом случае я добавляю еще один вторичный

00:04:39.545 --> 00:04:43.685
и я плачу нулевой ядер для этого.

00:04:43.685 --> 00:04:46.385
Таким образом, ваша архитектура может

00:04:46.385 --> 00:04:49.670
на самом деле использовать лучше
высокая доступность и

00:04:49.670 --> 00:04:53.765
аварийное восстановление с
более низкая стоимость владения

00:04:53.765 --> 00:04:55.730
с преимуществами сервера S'L, которые были

00:04:55.730 --> 00:04:58.525
изменил пост и в ноябре первого.

00:04:58.525 --> 00:05:01.520
Теперь, что это дает вам право сделать, это,

00:05:01.520 --> 00:05:05.995
Вы можете на самом деле принять это
любой релиз сервера S'L, 2019,

00:05:05.995 --> 00:05:10.370
2017, 2016, и всю дорогу

00:05:10.370 --> 00:05:12.980
к любому выпуску сервера S'L как

00:05:12.980 --> 00:05:16.145
до тех пор, как эти ядра
покрыто Software Assurance.

00:05:16.145 --> 00:05:19.250
Если у вас есть архитектура, которая,

00:05:19.250 --> 00:05:21.140
скажем, физическая машина.

00:05:21.140 --> 00:05:23.885
Так что если вы находитесь на
голый металл, вы получите это.

00:05:23.885 --> 00:05:26.074
Если вы находитесь на виртуальных машинах,

00:05:26.074 --> 00:05:27.860
вы также получите это преимущество.

00:05:27.860 --> 00:05:29.270
Если вы находитесь в контейнерах,

00:05:29.270 --> 00:05:30.770
вы также получите это преимущество.

00:05:30.770 --> 00:05:35.360
Независимо от того, используете ли вы S'L
Сервер в физическом центре обработки данных,

00:05:35.360 --> 00:05:39.125
или вы используете сервер S'L
в виртуальных машинах,

00:05:39.125 --> 00:05:42.200
или вы используете Azure
как ваш DR-центр

00:05:42.200 --> 00:05:46.745
и вы на самом деле хостинг
ваши праймериз в помещениях,

00:05:46.745 --> 00:05:49.010
вы будете иметь DR выгоды

00:05:49.010 --> 00:05:51.620
покрытие вашего сервера S'L
реплики на Azure.

00:05:51.620 --> 00:05:53.510
В следующих нескольких эпизодах,

00:05:53.510 --> 00:05:55.010
мы на самом деле говорить о том, что

00:05:55.010 --> 00:05:56.960
наиболее оптимальный
архитектуры, которые используют

00:05:56.960 --> 00:05:59.030
это преимущество эффективно.
Спасибо, что присоединились.

00:05:59.030 --> 00:06:10.690
(МУЗЫКА)