Как организовать хорошую отказоустойчивость ресурса?
Задался вопросом создания максимально отказоустойчивой системы для своего веб ресурса. Как я понимаю, необходимо зеркалирование во всём для достижения, соответственно, не понимаю как некоторые вещи зеркалировать. допустим, есть сайт, рогаикопыта.рф, как проходит доступ к сайту для пользователя: запрос к днсу, получение айпи, запрос к айпи, получение контента
Что именно не понимаю:
Запрос к днс. Очевидно, что для того, чтобы реализовать зеркалирование, нужны свои NS сервера. Очевидно, их нужно два, на разных провайдерах и, желательно, разных физических расположениях. Это понимаю. Дальше, как сделать так, чтобы днс проверял, какой айпи адрес с ресурсом жив и отдавал нужный айпи адрес? при условии что у меня будет 2 или более копии сайта? Тут еще проблема в том, что днс ведь кэшируется, и если он отдаст айпи, а потом тот упадёт, то он пойдет искать другой адрес или нет?
Ну и вообще, если вы расскажете, как делают отказоустойчивость "взрослые" сайты - будет круто.
Раньше для надёжного сайта достаточно было залить его в облако. После замечательно проделанной работы Роскомнадзора облака перестали быть надёжными чуть более чем полностью.
Просто хочу оставить заметку что доступность измеряется сервиса измеряется в процентах ( 100% - % времени, которое он не был доступен). По факту, 100% не существует, поэтому измерение производится в количестве девяток (например 99.99% - 4 девятки). Добавление к текущей доступности одной девятки увеличивает на 1-2 порядка стоимость сервиса в целом. Стоит задуматься - оно действительно необходимо?
Иван Шумов, понятное дело, но тут вопрос не в бизнес логике, а в моём умении при необходимости этой девятки бизнесу ее предоставить, и, желательно, не просто выносом в облако(как минимум понимать и то, как это сделать без оного, допустим, в банковском секторе)
MichaelShav, а вот тут надо понимать что HA это не про скейлинг) про. который уже писали вроде. Это про Failover и политики. У любой физической инфраструктуры есть предельная отказоустойчивость и с учетом проблем софта и проблем с сетью - конечная доступность приложения всегда невысокая. Мало-мальски приличный HA начинается с физически изолированных датацентов
два объекта балансировщика нагрузки имеют разные адреса, что произойдет, если балансир перестанет быть доступным после того, как пользователь подключиться к ресурсу? оно ведь будет закэшировано.
Делая "по-взрослому", обычно анонсируют для ресурса одни и те же адреса (свои) из нескольких точек. Это снимает остроту проблемы "DNS пользователя закэшировал неработающий айпишник". Как оно там потом внутри будет обрабатываться - другой вопрос.
MichaelShav, вроде того - организовать распределённую сетевую инфраструктуру, отказоустойчивость которой бы обеспечивалась таким образом. Это тема, отдельная от сервисов - чисто сетевая. Как там что внутри реплицируется - она не затрагивает, только надёжную связь с внешним миром.
Простой
