Witness server что это

Обновлено: 19.05.2024

Коротко о главном: каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. В каждой группе доступности может быть до 8 вторичных реплик.

Что это и зачем требуется

Группы доступности AlwaysOn — это решение высокой доступности и аварийного восстановления, является альтернативой зеркальному отображению баз данных на уровне предприятия. Если БД не справляется с потоком запросов или есть опасения, что при сбое на сервере пропадут ценные данные, есть смысл использовать это решение. Группы доступности AlwaysOn могут отвечать за выполнение сразу двух задачи: высокий уровень доступности обеспечивает бесперебойную работу системы, а нагрузка по чтению из БД частично выполняется на репликах.

Создание группы доступности может понадобиться, если вам необходимо:

Создать избыточную доступность баз данных (в этом случае рекомендуем располагать ноды в геоудалённых дата-центрах, т.к. избыточная доступность предполагает доступность БД при любых технических неполадках на любой из нод);

При отказе основой реплики, кластер проголосует за новую основную реплику и Always On переведёт одну из вторичных реплик в статус основной. Так как при работе с Always On пользователи соединяются с прослушивателем кластера (или Listener, то есть специальный IP-адрес кластера и соответствующее ему DNS-имя), то возможность выполнять write-запросы полностью восстановится. Прослушиватель также отвечает за балансировку select-запросов между вторичными репликами.

Подготовка инфраструктуры

Сначала необходимо создать виртуальную машину и пользователей. В VDC создаем 3 ВМ, даём имена согласно ролей, выполняем настройки кастомизации.

После этого переходим к этапу настройки контроллера домена. Устанавливаем роли AD, DNS, Failover Cluster.

Устанавливаем роль контроллера домена

Создаём в AD компьютеры ND01 и ND02.

На ВМ ND01 и ND02 ставим компонент Failover Cluster

Теперь переходим к созданию кластера отказоустойчивости. На контроллере домена DC01 создаём кластер отказоустойчивости и добавляем в него наши ноды.

Даём имя кластеру.

При создании кластера снимаем галочку с добавления массивов в каталог. Эту настройку можно сделать позже.

Создание кластера завершено.

Создание свидетеля (Quorum Witness Share)

Переходим к настройке кворума. Для этого выбираем пункты, которые указаны на скриншоте.

В конфигурации свидетеля кворума указываем file share.

После этого необходимо создать директорию на сервере, не участвующем в кластере, но имеющим общую сеть с кластером. После создания такой директории и добавления шары для доступа к ней нод из кластера, в настройке свидетеля нужно указать UNC путь.

Если после создания свидетеля у вас возникнет ошибка как на примере ниже,

…то в этом случае необходимо проверить настройки прав доступа к сетевой директории, указанной в настройках свидетеля.

Переходим к установке MS SQL 2015 Enterprise на ноды в кластере. Перед установкой модуля необходимо отключить брандмауэр на работу в доменной сети на всех ВМ, участвующих в кластере.

Устанавливаем MS SQL в standalone режиме, без дополнительных модулей. При выборе пользователя для примера берём Администратора доменной сети. Для боевых серверов рекомендуем сделать отдельного пользователя. Наверное, не нужно объяснять, почему это важно.

Затем необходимо установить SQL Management Studio на обе ноды в кластере.

Добавление тестовой базы данных в MSSQL

На ноде ND01 устанавливаем тестовый образец базы данных. Имя тестовой БД будет Bike-Store. Тестовая БД взята отсюда.

После установки БД выделяем созданную базу данных, после чего выбираем файл БД при помощи комбинации Ctrl+O.

После открытия файла нажимаем «Выполнить»

Важно! Перед развертыванием группы доступности обязательно делаем резервную копию БД, в противном случае не получится создать группу доступности

Настройка Always On в MS SQL Server

Для каждой ноды необходимо включить поддержку схемы AlwaysON в SQL Server Configuration Manager в свойствах экземпляра.

На ноде ND01 В SQL Server Management Studio выберите узел «Always On High Availability» и запустите мастер настройки группы доступности (New Availability Group Wizard).

Присваиваем имя нашей группе доступности: BikeStores-AG

Нажмите «Добавить реплику» и подключитесь к второму серверу SQL. Таким образом можно добавить до 8 серверов.

Ключевые параметры

Исходная роль – роль реплики на момент создания группы. Может быть Primary и Secondary;

Автоматический переход – если база данных станет недоступна, Always On переведёт primary роль на другую реплику. Отмечаем чекбокс;

Режим доступности – возможно выбрать Synchronous Commit или Asynchronous Commit. При выборе синхронного режима транзакции, поступающие на primary реплику, будут отправлены на все остальные вторичные реплики с синхронным режимом. Primary реплика завершит транзакцию только после того, как реплики запишут транзакцию на диск. Таким образом исключается возможность потери данных при сбое primary реплики. При асинхронном режиме основная реплика сразу записывает изменения, не дожидаясь ответа от вторичных реплик;

Вторичная реплика для чтения – параметр, задающий возможность делать select-запросы к вторичным репликам. При значении yes, клиенты даже при соединении без ApplicationIntent=readonly смогут получить read-only доступ;

Для фиксации требуются синхронизированные получатели – число синхронизированных вторичных реплик для завершения транзакции. Нужно выставлять в зависимости от количества реплик. Имейте в виду, что, если вторичных синхронизированных реплик станет меньше указанного числа (например, при аварии), базы данных группы доступности станут недоступны даже для чтения.

На вкладке Параметры резервного копирования можно выбрать откуда будут делаться бекапы. Оставляем всё по умолчанию – Предпочитать вторичную.

Указываем имя слушателя группы доступности, порт и IP-адрес.

Если все тесты во время окончания прошли успешно, то нажимаем кнопку «Далее».

На этом первичная настройка группы доступности AlwaysON завершена. Вы можете провести тесты отказоустойчивости, попеременно отключая каждую ноду в кластере, а также давая простые запросы select, insert.

Надеемся, наша инструкция по создании групп доступности поможет вам обеспечить надлежащий уровень работоспособности вашей ИТ-инфраструктуры. В дальнейшем мы планируем выпустить и другие варианты сценариев. Если вам интересны какие-то нюансы – напишите о них в комментариях. Спасибо за внимание!

В России стартовала распродажа «Киберпонедельник-2021». Мы тоже решили принять участие в этой акции, и на три дня открыли бесплатный доступ к видеокурсу «Управление виртуальным дата центром и сетями в vCloud Director (VMware)» специально для тех, кто хочет разобраться в этой теме и научиться управлять облачной инфраструктурой.

В результате вы и ваши сотрудники сможете эффективнее использовать облачные платформы и больше не будете не путаться при работе с виртуальными машинами.

Курс уже получил 91 оценок от 366 студентов, средняя оценка — 4,5. Сейчас он снова бесплатно доступен на Udemy! Регистрируйтесь и учитесь!

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Segregated witness benefits

Теперь, когда мы разобрались с технической частью, рассмотрим основные преимущеста segregated witness.

Transaction malleability

Одной из самых важных проблем, которые решает segwit является "изменяемость" транзакций, а если точнее, то их ID, являющиеся хешами. Разберемся немного подробнее.

В традиционном случае подписи, находящиеся внутри транзакции во входах, могут быть изменены третьей стороной без их инвалидации. Это позволяет изменять ID транзакции, являющийся ее хешем, не меняя никаких "фундаментальных" полей вроде входов/выходов/количества средств. Таким образом транзакция все еще валидна, однако теперь имеет другой ID, что создает возможность для разного рода атак, например denial-of-service.

Segwit решает эту проблему, т.к все подписи находятся снаружи транзакции, а значит не хешируются и их изменение никак не повлияет на ID транзакции. Также вводится отдельный идентификатор wtxid — он хеширует не только транзакцию но и всю witness часть, так что если транзакция передается без witness данных, то txid равен wtxid.

Решение данной проблемы позволяет создавать цепочки неподтвержденных транзакций без какого-либа риска — очень важное свойство для таких протоколов как Lightning Network.

Network and Storage Scaling

Witness данные зачастую составляют самую большую часть транзакции. В скриптах наподобие multisig'a они могут занимать до 75% места используемого транзакцией. Благодаря segwit'y передача подписей становится опциональной — нода запрашивает их только если собирается проводить валидацию транзакции. SPV (simple payment verification) клиенты или ноды, не поддерживающие сегвит, в таком случае могут не загружать лишние данные, экономя место на диске.

Block size increase and lower transaction fees

Segwit транзакции обходятся дешевле, нежели традиционные за счет скидки на хранение witness данных. Если быть точнее, то было изменено само понятие "размера" для segwit транзакций. Вместо обычного размера для них было введено понятие "виртуального размера" (virtual size) — все данные, хранящиеся в "witness", учитываются с коэффицентом в 0.25, что также позволяет разместить в блоке больше транзакций. Рассмотрим на примере.

Пусть у нас есть традиционная транзакция размером в 200 байт. В блок размера 1 МB поместится 5000 таких. Теперь возьмем ее segwit эквивалент, где примерно 120 байт это witness данные. Тогда ее vsize = 80 + 0.25 * 120 = 110 и теперь уже 9090 таких транзакций влезут в блок. Также при комиссии, допустим, в 40 satoshi/byte для 1ой транзакции мы получим комисси в 8000 сатоши, а для 2ой 4400 сатоши, что практически в два раза меньше.

Script Versioning

Как вы уже могли заметить, каждый locking script имеет байт, отвечающий за версию скрипта. Использование версий позволяет вносить дополнения и изменения (изменения в синтаксисе, новые операторы и тд.) в виде софт-форков.

Signature Verification Optimization

Segregated Witness также оптимизирует работу алгоритмов с подписями (CHECKSIG, CHECKMULTISIG и тд.). До segwit'a количество хеш-вычислений увеличивалось квадратично от количества подписей, в то время как в обновлении сложность алгоритма понижена до O(n).

How it works

Before we begin

Поле PubKey script (далее scriptPubKey) в выходах это то, что называют locking script. Оно нужно для того, чтобы только владелец адреса, на который перечисляются срества, смог воспользоваться этим выходом. Поле Signature Script (далее scriptSig) еще называют unlocking script — оно "отпирает" locking script, предоставляя доказательство владения адресом.

Подробнее о транзакциях, а также о работе запирающего и отпирающего скрипта можно почитать здесь.

Backward compability

На самом деле, Segregated Witness меняет не только строение транзакции, но и ее выходы. Это, однако, не значит, что в одной и той же транзакции не могут быть потрачены как традиционные UTXO (unspent transaction outputs), так и сегвитовские — просто первые будут ожидать "доказательства" внутри входа (поле scriptSig), а вторые — снаружи.

Так как Segregated Witness все-таки является софт-форком, его обновления могут быть проигнорированы, а значит более старые системы должны как-то обрабатывать сегвитовские выходы. Дело в том, что для старых нод или кошельков эти выходы выглядят как доступные всем, то есть они могут быть потрачены с пустой подписью, что все еще валидно. Принявшие обновление ноды и кошельки конечно же будут искать все подписи снаружи входов в специальном поле 'witness'.

Examples

Pay-to-Witness-Public-Key-Hash

Теперь давайте взглянем на примеры транзакций и на то, как они изменятся с Segregated Witness. Мы начнем со стандартной Pay-to-Public-Key-Hash (P2PKH) транзакции.

Нас интересуют выходы, а именно их поля "scriptPubKey". Рассмотрим типичный locking script:

C Segregated Witness он будет выглядеть так:

Как видите, сегвитовский выход намного проще традиционного — он состоит из двух значений, которые будут помещены на стэк исполнения скрипта. Как мы уже упомянули ранее, для старых версий клиента биткоина этот выход будет виден как доступный любому, так как он не требует подписи. А вот для обновленного клиента первое число интерпретируется как номер версии, а второе как аналог запирающего скрипта (witness program). На самом деле, здесь должен быть использован хеш сжатого публичного ключа, об этом мы расскажем немного позже.

Теперь давайте рассмотрим транзакцию, в которой этот выход будет потрачен. В традиционном случае это выглядело бы так:

Однако, чтобы потратить сегвитовский выход, транзакция должна иметь пустое поле sriptSig и содержать все подписи в отдельном месте:

Warning

Несмотря на то, что традиционные клиенты могут обрабатывать сегвитовские транзакции (напомню, что их выходы выглядят как доступные всем для старых клиентов), они не могут тратить их выходы, так как они просто не знают, как это сделать: кошелек старого типа попытается потратить сегвитовский выход с пустой подписью, однако эта транзакция на самом деле не валидна (ноды, имеющие Segregated Witness, не пропустят такую транзакцию). Это значит, что отправитель должен знать, поддерживает ли кошелек получателя segwit или нет, чтобы создавать выходы нужного типа.

Начиная с BIP 143 выходы должны быть созданы с помощью хеша сжатого публичного ключа. Если вы создадите выход используя обычный адрес или несжатый публичный ключ, этот выход будет неиспользуемым.

Pay-to-Witness-Script-Hash

Следующим очень важным типом транзакции является P2SH — он позволяет отправлять транзакции на хеш скрипта вместо хеша публичного ключа (обычный адрес биткоина). Чтобы потратить выход P2SH транзакции нужно предоставить скрипт (его называют redeem script), хеш которого совпадает с хешем скрипта на который отправлены средства, а также подписи/пароли/что-то еще в зависимости от скрипта. Используя такой подход можно отправлять биткоины на адрес, защищенный способом, о котором нам ничего не известно, а также сильно экономить место — в случае, например, кошелька с мультиподписью (multisignature wallet) locking script был бы действительно большим, если бы мы хранили все "замки" полностью, а не только их хеш.

Итак, рассмотрим в качестве примера кошелек с мультиподписью, требующий наличия 2ух подписей из 5. В традиционном виде locking script выхода P2SH транзакции выглядит так:

Чтобы потратить его, нужно предоставить redeem script, определяющий условие мультиподписи 2 из 5, а также 2 подписи и все это должно находится во входе транзакции:

Теперь давайте взглянем, как бы все это выглядело, если бы и отправитель и получатель использовали Segregated Witness.

Locking script выхода:

Опять же, как и в случае с P2PKH транзакцией полученный скрипт намного проще. Здесь 1ое значение это номер версии, а второе — 32 байтный SHA256 хеш redeem script'a (witness program). Эта хеш-функция была выбрана для того, чтобы как-то отличать witness program P2WPKH от оной для P2WSH по длине хеша (32 байта SHA256 и 20 байт RIPEMD160(SHA256(script))).

Транзакция, использующая этот выход:

Embedding Segregated Witness inside P2SH

Итак, мы убедились, что использование Segregated Witness имеет свои преимущества, однако для приведенных выше примеров и отправитель и получатель должны быть обновлены, что возможно далеко не всегда. Рассмотрим, например, такую ситуацию:

В таком случае Боб может создать P2SH адрес, содержащий в себе segwit скрипт. Для Алисы он будет виден как самый обычный P2SH адрес и она сможет без каких либо проблем перевести на него средства, а Боб сможет потратить этот выход используя сегвит-транзакцию и получив скидку на комиссию (о новой метрике установления комиссии для сегвит транзакций мы расскажем ниже).

Таким образом оба типа сегвит-транзакций — P2WSH и P2WPKH могут быть реализованы внутри P2SH.

P2SH(P2WPKH)

Для использования P2WPKH транзакции внутри P2SH Бобу нужно создать witness program из своего публичного ключа. Затем результат нужно хешировать и преобразовать в P2SH адрес:

Создаем witness program:

Как обычно — 1ое число это версия и 2ое это 20 байтный хеш публичного ключа. Полученный скрипт затем хешируется SHA256 и потом RIPEMD160, выдавая очередной 20 байтный хеш.

HASH160 от witness program P2WPKH:

И преобразовываем в адрес:

Locking script выхода отправленного на этот адрес будет выглядеть как скрипт для обычного P2SH адреса:

Теперь рассмотрим как Боб может потратить этот выход:

Сначала предоставленный нами redeem script (в нашем случае это witness program) будет хеширован и, если он равен хешу, указанному в locking script'e, то он будет выполнен и будут проверены подписи в поле "witness".

P2SH(P2WSH)

Точно также любой P2WSH скрипт может быть реализован внутри P2SH. Возьмем multisig скрипт 2 из 5, рассмотренный ранее. Все шаги будут практически идентичны случаю P2SH(P2WPKH):

Для начала, опять же, создаем witness program:

1ое число — версия, 2ое — 32 байтный SHA256 хеш нашего скрипта мультиподписи. Далее шаги повторяются — берем HASH160 от witness program и преобразовываем в обычный P2SH адрес. Для использования выхода, отправленного на этот адрес, в scriptSig нужно записать witness program, а все подписи и полный скрипт мультисига в поле witness.

Использование следящего сервера в нескольких сеансах

Заданный экземпляр сервера может выступать в роли следящего сервера в нескольких параллельных сеансах зеркального отображения базы данных для разных баз данных. В этих сеансах могут присутствовать различные участники. На следующем рисунке показан экземпляр сервера, который является следящим в двух сеансах зеркального отображения базы данных с различными участниками.

Кроме того, один и тот же экземпляр сервера может одновременно выступать в качестве следящего сервера в одних сеансах и в качестве участника зеркального отображения в других. Однако на практике экземпляр сервера обычно выступает либо в качестве следящего сервера, либо в качестве участника зеркального отображения, так как для обслуживания производственной базы данных участники требуют мощных и сложных систем с серьезными требованиями к оборудованию, в то время как следящий сервер может работать на любой доступной системе Windows, обеспечивающей работу SQL Server.

Database Mirroring Witness

Для поддержки автоматической отработки отказа сеанс зеркального отображения базы данных должен быть настроен на использование режима высокой безопасности, а также должен присутствовать третий экземпляр, называемый следящим сервером. Следящий сервер это дополнительный экземпляр SQL Server , позволяющий зеркальному серверу в сеансе режима высокой безопасности определить, следует ли начать процедуру автоматической отработки отказа. В отличие от двух участников зеркального отображения, следящий сервер не обслуживает базу данных. Его единственная функция заключается в поддержке автоматического перехода на другой ресурс.

В режиме высокой производительности следящий сервер может неблагоприятно повлиять на доступность ресурсов. Если для сеанса зеркального отображения базы данных настроен следящий сервер, то основной сервер должен быть подключен по крайней мере к одному из двух других экземпляров сервера — зеркальному или следящему серверу. В противном случае база данных становится недоступной, а принудительное восстановление службы невозможным, при этом могут быть потеряны данные. Таким образом, в режиме высокой производительности настоятельно рекомендуется всегда поддерживать параметр WITNESS в значении OFF. Дополнительные сведения о том, каким образом следящий сервер влияет на режим высокой производительности, см. в разделе Режимы работы зеркального отображения базы данных.

Следующий рисунок иллюстрирует сеанс в режиме высокого уровня безопасности с участием следящего сервера.

В этом разделе:

Построение отказоустойчивых систем на базе Exchange 2010

Доброго времени суток!
Данная статья описывает мой опыт построения отказоустойчивого почтового сервиса Microsoft Exchange 2010 SP1.
Она полезна по большей части новичкам для того, чтобы разобраться в теории.
Я не буду углубляться в практические аспекты, а постараюсь изложить теоретическую базу, необходимую при построении отказоустойчивого кластера Exchange.
Все остальное – под катом. (Много текста!)

Итак, если наша задача – построить отказоустойчивую почтовую систему на базе Exchange 2010, то единственным (приемлемым) вариантом будет использование DAG (Database Access Group).
Помимо DAG нам потребуются еще несколько серверов для обеспечения отказоустойчивости необходимых ролей Exchange. О них будет рассказано чуть позже.

В связи с поставленными передо мною целями я стал работать по следующей схеме (небольшое уточнение – канал между датацентром и офисом 30 Мб/с синхронный):

Напомню, что в Exchange 2010 элементами DAG-массива могут быть не только Mailbox-сервера, поэтому это сильно упрощает работу в сравнении с версией 2007.

Первое что я делаю – это выношу Edge Transport в DMZ средствами TMG и на том, и на другом сайте.
В DNS-записях для своего домена я прописываю 3 MX записи с различным приоритетом – одна указывает на TMG в Datacenter, другая на шлюз в Office, третья на резервный канал в офисе, который также заведен в TMG и настроен через ISP Redundancy (Failover). Это делает выполненным четвертый пункт из списка моих целей – свести к минимуму вероятность потерять входящую почту.

В случае, если в датацентре пропадает интернет/выходит из строя сервер – вся входящая почта приходит на сервер в офисе. Единственным вариантом, при котором почта все-таки может не дойти, если интернет пропадет сразу и в датацентре, и в офисе (на двух каналах!) более чем на 30 минут.

Следующее — это обеспечить отказоустойчивость для клиентов, использующих Outlook 2010 во внутренней сети. Для этого требуется обеспечить отказоустойчивость роли Mailbox и Client Access.
На 2х Exchange-серверах с ролью Mailbox на разных сайтах создается 2 базы данных – одна активна на первом сайте, вторая активна на другом.

Для чего это нужно:
1) Распределение нагрузки, если все работает в штатном режиме.
2) В случае если сервер в датацентре выходит из строя/становится недоступен, в офисе у нас есть копия базы, которая автоматически перейдет в Active mode. Пользователи смогут продолжить работу.
3) Возможность проводить сервисное обслуживание серверов, переключая активные сервера «на горячую».

При создании DAG-кластера из GUI, Вам потребуется указать как минимум один сервер File Witness. Сервер File Witness (файловый свидетель), если говорить очень грубо, это сервер с расшаренной папкой, который будет поддерживать голоса в кворуме, в случае выхода из строя одного из Mailbox серверов. Он нужен для того, чтобы после того, как сервера, которые были некоторое время недоступны, станут Back-online, смогли синхронизировать (читай реплицировать) изменения с других членов кластера и при этом не «запутаться», что на них уже есть, а чего не хватает.

Я создал по одному File Witness серверу на каждом сайте (т.к. в случае падения интернета на одном из сайтов, для второй части Exchange-сервера становятся недоступны как Mailbox, так и File Witness сервера) для поддержания кворума. Но задача обеспечить отказоустойчивость клиентов Outlook еще не выполнена.

На данном этапе возникает вопрос: «Но в Outlook у всех же прописан определенный сервер Client Access?! И если он станет offline, то куда будут подключаться клиенты?».

Именно для того, чтобы не допустить такой ситуации используется Network Load Balancing Services (службы балансировки нагрузки на сеть). Я использовал возможности, которые имеются у ОС Windows Server 2008 R2 с ролью Cluster Services, однако Microsoft настоятельно рекомендует использовать «железные» NLB.
В качестве серверов NLB я использовал File Witness сервера для экономии ресурсов.

На NLB я настроил балансировку нагрузки между двумя серверами Exchange с ролью Client Access.
При этом эти сервера [прим. – Client Access] не являются серверами Mailbox! Настоятельно рекомендую Вам разносить данные роли по различным серверам/виртуальным серверам.

Так я выполнил первый пункт из списка своих целей – отказоустойчивость для клиентов Outlook во внутренней сети.

Небольшое дополнение – на NLB я настроил VIP-адреса (вся внутренняя подсеть), которые ВСЕГДА (за исключением, когда сервер недоступен) будут работать с Exchange в офисе – для уменьшения траффика в интернет и увеличения быстродействия. Только в случае, если 1 из серверов выходит из строя, клиенты переключаются на другой Client Access-сервер (между прочим это правило действует также и для мобильных устройств, которые подключаются к офисному Wi-Fi, т.к. на их DNS-запросы возвращаются IP-адреса из локальной сети). Для меня это было актуально, т.к. на втором сайте у меня клиентов нет.

Segregated Witness для чайников

Масштабируемость биткоина является одной из его главных проблем, над решением которой активно работают. Одним из представителей этих решений является, например, технология Lightning network, но ее реализация пока что не представляется возможной ввиду некоторых уязвимостей. Другое решение — Segregated Witness также направлено на повышение масштабируемости, но ко всему прочему решает еще и целый ряд проблем, включая ту самую уязвимость, мешающую реализации лайтнинга. В этой статье мы рассмотрим основные преимущества Segregated Witness, а также опишем механизм его работы.

Segregated witness, или как многие его называют SegWit, это софт-форк, описанный в серии BIP'ов (141, 142, 143, 144 и 145), главной целью которого является оптимизация структуры транзакций и блоков с помощью вынесения подписей (то, что называют 'scriptSig', 'witness' или же 'unlocking script') из транзакции в отдельную струтуру. Это не только позволяет уменьшить размер транзакций, делая блоки более вместительными, но и решает проблему их "изменяемости" (transaction malleability, именно об этой уязвимости мы и говорили выше), что очень важно для технологий наподобие платежных каналов или лайтнинга, пологающихся на строение транзакции биткоина.

Роль следящего сервера в автоматический переход на другой ресурс

На всем протяжении сеанса зеркального отображения базы данных все экземпляры сервера отслеживают свое состояние соединения. Если произошло отсоединение участников друг от друга, то они, чтобы гарантировать, что в данный момент только один из них обслуживает базу данных, полагаются на следящий сервер. Если синхронизированный зеркальный сервер теряет соединение с основным сервером, но остается соединенным со следящим сервером, зеркальный сервер обращается к следящему серверу, чтобы определить, потерял ли следящий сервер соединение с основным сервером.

Если основной сервер до сих пор подключен к следящему серверу, то автоматическая отработка отказа не производится. Вместо этого основной сервер продолжает обслуживать базу данных, накапливая записи журнала для отправки на зеркальный сервер при повторном соединении участников.

Если следящий сервер также отключен от основного сервера, то зеркальный сервер считает, что основная база данных стала недоступна. В этом случае зеркальный сервер инициирует немедленную автоматическую отработку отказа.

Если зеркальный сервер отключен от следящего и основного серверов, то автоматическая отработка отказа невозможна вне зависимости от состояния основного сервера.

Требование, которое заключается в том, чтобы по крайней мере два экземпляра сервера оставались подключенными, называется кворумом. Кворум гарантирует, что в каждый момент времени база данных может обслуживаться только одним участником. Дополнительные сведения о кворуме и влиянии, которое он оказывает на сеанс, см. в разделе Кворум. Как следящий сервер влияет на доступность базы данных (зеркальное отображение базы данных).

So what is the problem?

Так если все так хорошо, в чем же проблема? Обновление имеет немало противников в сети, так как несмотря на все очевидные преимущества, оно имеет и свои слабые стороны. Рассмотрим некоторые из аргументов против.

Так как segwit является софт-форком, обновлены будут далеко не все клиенты, а значит в сети будут находится одновременно два вида UTXO, и такие важные изменения как устранение уязвимости id транзакций и хеширование за линейное время не будут применены к не сегвитовским выходам, а значит сеть все еще будет уязвима к атакам, основанным на изменяемости id транзакций, а также к проблеме квадратичного времени хеширования.
Segwit может уменьшить безопасность сети. Количество нод, проводящих полную валидацию, сильно уменьшится, так как только принявшие segwit смогут проверять witness часть транзакций.
Segwit не может быть отменен. Если его отменить и откатить все изменения обратно, все segwit-выходы станут доступными каждому.
Segwit пытается решить все проблемы сразу и, как следствие, огромное количество кода изменено. Это усложняет дальнейшую работу и увеличивает вероятность появления багов, которые будет сложнее устранить.

Conclusion

Несмотря на то, что, возможно, для проблем, решаемых SW, могут быть предоставлены более элегантные решения, мы считаем, что на данный момент это отличный способ повысить масштабируемость сети, а также сделать возможным внедрение таких технологий как Lightning Network, подробный разбор которой мы также проведем в следующих статьях.