alexeyvgТолько Azure SQL DB может быть в десятки раз дороже, а администрирования не факт, что убавится. Конечно, админы нужны будут другие, не по жэелезу и сиквелу, а по Ажуру, и Azure SQL DB.
А чаще всего администрирования добавляется, потому что старые то остаются, у фирмы же не одна эта база и не один сервер.

Нужно считать конкретные варианты, облако не стоит по умолчанию дешевле , оно может стоить дешевле, но далеко не всегда.

именно поэтому я написал "посмотрите Azure SQL DB", а не "лучшее решение для вас это Ажур"
автору виднее что у него за ситуация и каковы ограничения/возможности/требования

Molochnikпропущено...

То есть фактически это работает так:
1) Два обычных сервера с Win Server, на каждом своя лицензия SQL Std, оба сервера настроены на работу с BAG

лицензируется только активный сиквел
если база недоступна для подключения, сиквел не лицензируется

Molochnik2) На одном сервере база - на другом реплика. Все приложения подключаются к основной базе.

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

Molochnik3) С каждым коммитом реплика обновляется

зависит от настроенного режима (sync vs async)
sync - вторичная реплика обновляется до коммита на первичном сервере
async - вторичная реплика обновляется по коммиту

Molochnik4) Реплика для Std BAG не читается и поэтому нельзя подключаться к реплике если работает основная база

да
но можно создавать snapshot и читать версию базы на момент снэпшота
вторая лицензия при этом требуется

Molochnik5) Если сдыхает сервер с репликой все работает как и работало, при восстановлении сервера - реплика обновляется.

зависит от самой причины
например, если второй сервер ушел в небытие, то нужно перенастраивать BAG

Molochnik6) Если сдыхает сервер с основной базой, все приложения должны переключиться на работу с репликой (поменять IP адрес в коннектах), которая теперь работает. Если сервер включается приложения должны переконнектиться к основной базе

чтобы не менять IP в коннектах, приложения надо подключать к листенеру
BAG группа поднимет базу и листенер на втором сервере

Molochnik6) При синхронной настройке базу идентичны в онлайн режиме, но возможны тормоза при коммитах

при sync ваша транзакция на первичной реплике зависит задержек сети и задержек на вторичном сервере (log hardening)
поэтому, рекомендуется иметь идентичное железо и быструю сетку

в противном случае, следует использовать async

Molochnikkomrad,
Это выглядит для меня как полностью рабочая схема, поэтому хотел бы ясность для себя внести как все это настраивается и понять все эти микрософт технологии:
1) Два сервера, на каждом Windows Server. Или Win10 достаточно? Обе машины в общую сеть вероятно входить не будут.


https://docs.microsoft.com/ru-ru/sql/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability?view=sql-server-2017

https://docs.microsoft.com/ru-ru/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server?view=sql-server-2017#TOP_Principal

Standard Edition поставится на 10-ку, но я не уверен, что она поддерживает кластеризацию

Molochnik2) AD надо ли поднимать? Или можно обойтись? Если настраивать то как? Один лес, два домена?

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

Molochnik3) Насчет кластера. Нужен ли он? Иди полностью альтернатива BAG? Везде касательно кластеров Микрософт используют термин "failover" кластер. Вы же написали что если диск накрывается, то база тоже накрывается. Как это может быть? В чем тогда "отказоустойчивость" кластера? Можно ли на уровне кластера настроить автоматическую оффлайн синхронизацию? Например ночью база синхронизируется, в основное время работаешь с одной базой, если сервер накрылся, автоматически переключается на работу с архивной (вряд ли ее можно назвать репликой).

для AlwaysON должна быть запущена служба кластеризации
BAG для своей работы требует ее
кластеризуется не сам сиквел, а только BAG

failover кластер подразумевает один разделяемый сторадж в один момент времени подключенный только к тому серверу (диски в онлайне), на котором работает кластерная группа в данный момент

отказоустойчивость кластера в нескольких нодах, способных подхватить нагрузку "упавшего" сервера
сторадж считается надежным по умолчанию, т.к. используется многократное резервирование дисков (рейды)
такой сетап называется high availability

если содержимое стораджа копируется на другой сторадж (например, в другом датацентре) - это уже disaster recovery

обычно, чем большая надежность и отказоустойчивость требуется, тем дороже это стоит

поэтому сначала определяют риски, требования к доступности, а потом уже строят саму систему в соответствии с ними



Molochnik5) Насчет BAG. На одну машину ставится MS SQL std. На вторую(резерывную) что? Ничего? Она будет подхвачена в группу BAG автоматически при настройке BAG? Listener - это я так понимаю виртуальная машина, входящая в BAG и имеющая IP адрес, которому и идет подключение? Вы сказали можно сделать снапшот резервной базы если поставить на нее еще один MS SQL Std? А зачем вообще этот снапшот может понадобиться? Просто чтобы посмотреть и убедиться, что все в порядке с резервной базой?

вторая машина - копия первой
с таким же железом, операционкой, дисками и сиквелом
она будет добавлена как availability replica в процессе настройки BAG

Listener - это пара hostname+IP, которая "ездит" вместе с базой по нодам, отвечает за принятие коннектов приложений
приложения могут коннектится напрямую к сиквелам, но могут попасть на вторичную реплику, которая недоступна для чтения
если приложения коннектятся к листенеру, то они всегда подключатся к активной базе

снепшот можно создавать для чтения с неактивной базы (вторичная реплика) в целях уменьшения нагрузки на первичную реплику
нужен ли он вам - вам виднее
я просто указал на возможность



Molochnik6) После того как все настроишь, могут ли клиентские приложения спокойно работать на самих серверах?

безусловно

MolochnikКритикпропущено...

Вам лень почитать описание?
Там вычислительная часть дублируется, а СХД (диски) одно.

Просто утомился читать детали, не понимая картины в целом. Вычислительная часть дублируется, а диски нет? То есть предполагается что процессор или память слабые места системы, а диски супернадежны? Бред какой-то. И эта "кластерная технология" называется "failover" и долго была передовой у микрософта?
под дисками подразумевается SAN, подключаемый к серверам по оптике или подобным способом
типа такого

Molochnik,

примерная топология в случае с SAN storage



Library написано с ошибкой ;)