Для Ирландии от России физ. лицо предоставляет фото паспорта РФ.
Страницы с именем и с пропиской.
Там, в Адсенсе, прямо так и написано. Бессрочно.
Можете начать от сюда https://ru.wikipedia.org/wiki/VRRP
Спасибо, это один из самых интересных материалов по IT, что я читал в этом месяце.
С первой итерации не получилось понять как всё это взаимодействует с TCP-IP, какой путь проходит пакет и много других деталей. Но даже для далёкого от сетей человека понятно в каком направлении следует изучать дальше.
Первое понимание такое:
1. Несколько маршрутизаторов, объединенных в один виртуальный, находятся на одном IP и получают одинаковые пакеты.2. Между собой они решают, кто обработает эти пакеты и отправит дальше.3. Один выбранный маршрутизатор обрабатывает пакет, остальные ждут.4. Если некоторые маршрутизаторы выключены, то оставшиеся продолжают работать по тому же принципу в сответствии с их приоритетами.
Общие принципы описаны верно?
Если так, то пока непонятно, возможно ли назначить один IP маршрутизаторам из разных датацентров? Похоже, что для этого в каждом из двух ДЦ должна быть одна AS. Теоретически это наверно возможно в случае, когда оба ДЦ принадлежат одной компании.
Один комментарий на хабре также похоже намекает, что обрыв аплинка одного из маршрутизаторов, который не выключен, без дополнительных настроек и/или железа может приводить к появлению blackhole для пакетов.
Кстати, вариант - поднимать инстансы с приложением, у которых локальная база будет в SQLITE, а важные изменяемые данные - подтягиваться и обновляться с управляющего сервера по API с БД в надёжном ДЦ.
Если нагрузки небольшие, управляющий сервер может сам создавать и запускать такие инстансы в работу по мере их падения, а также время от времени актуализировать локальные БД для повышения их производительности.
Время на переключение DNS будет не слишком малым. Но можно поднять свой DNS с API и выставить на нём минимальное TTL. Либо найти провайдера DNS с API и возможностью устанавливать такое минимальное TTL.
Legal notice: Конечно же, противозаконное использование таких технологий недопустимо !0!
балансировщик с резервированием это значит что если упадет ДЦ с балансировщиком, то IP адрес уйдет другому балансировщику в другом ДЦ, вам как клиенту ничего делать не надо для этого, только платить.
Это интересная штука. Раньше знал только про FailoverDNS, которые перключаются не мгновенно, а за пару минут или даже сильно дольше. Как, интересно, такое может быть реализовано, надо почитать...
балансировщик с резервированием,
ОП, похоже, хочет быть защищенным от падений именно ДЦ.
А когда падает ДЦ, то балансировщики должны упасть вместе с ним. Иначе зачем разносить сервера именно по разным ДЦ?
Если датацентр работает хорошо, вместе со всеми своими балансировщиками, то наличие копии приложения в другой локации поможет мало.
Балансировщик может помочь решить проблемы горизонтального масштабирования в рамках одного ДЦ.
В задаче ОПа нужно либо работать на уровень выше - это DNS, либо как условный Google переходить на железные сверхпроизводительные балансировщики где-то в изолированных защищенных многократно резервированных строениях, которые никогда не падают, не перезагружаются и хитро связаны между собой и серверами.
В Селектеле балансировщики держат, как понял, 34000RPS HTTP или 9000 HTTPS. Это не так, чтобы много. Исходя из этих значений, положить его с помощью спец.сервиса сможет даже небогатый школьник (извините, настоящие школьники, речь не о вас, это старый IT-термин, обозначающий молодых, безответственных хулиганов, которым по причине малого возраста ничего не грозит даже в случае поимки).
В жизни мне дважды доводилось сталкиваться с одним типом атак, от которых шевелились волосы на голове. Это когда нагрузка на сами сервера в порядке, а сеть накрывает волнами непонятных снижений пропускной способности. Может быть это были какие-нибудь DNS-амплификации или атаки непосредственно на сетевые устройства на более низких уровнях OSI. Сложно сидеть и понимать, что ничего не можешь сделать. А тут - чужой балансировщик, который непонятно как настроен, что на нем происходит и как его защищать. "Школьники" кинут копейку крипты на стpeсcбот и начнётся веселье. И что делать, когда всё уже завязано на этом балансировщике?
Облачная БД - это интересно. Раньше запросы к ним были значительно дороже, чем при использовании баз данных на своих серверах, а скорость доступа была чуть ниже. Было бы интересно посмотреть насколько ситуация стала лучше за несколько лет.
UPD.: Ну вот, по облачным базам в Селектел. Три хилых 16-ядерных сервера в СПб
PostgreSQL 14Санкт-Петербург32 vCPU128 ГБ RAM1024 ГБ дискПодсеть /29 (5 адресов IPv4)2 репликиИтого: 243 855,13 ₽/мес.
Как сделать географическое распределение пока не понял.
И за эту цену я наверно собрал бы конфигурации поинтереснее на условном AMD 7443P.
Если посмотреть на разные сообщения разных авторов, можно заметить, что мы одновременно обсуждаем несколько разных понятий из разных направлений проектирования и конструирования инфраструктуры, порой даже находящихся на разных уровнях абстракций.
Каждая из этих тем довольно сложна. А когда они перемешиваются, сложность коммуникации еще более возрастает.
Резервирование, масштабирование, надёжность, мониторинг, доступность, устойчивость к сбоям, удобство и скорость развертывания, применимость для разных типов приложений и в разных ситуациях, архитектура баз данных, взаимодействие с ДЦ и многие другие темы - по каждой из них можно писать монографию и даже в ней не охватить полностью все многочисленные детали.
Информации о проекте почти нет.
IP разные, VDS-ы тоже на разных хостингах, домен один и тот же. Требуется «бесшовно» переключать одну машину на другую при падении «головной». Как вы это реализуете?
Да никак мы это не реализуем. Я о задаче такой сложности читал только один раз, когда обсуждалось как транснациональные корпорации из ТОП-10 организуют доступность своих сервисов по всему миру.
Насколько помню (так как читал давно), у них используется спец.железо, на котором строится некая сетевая структура. Спецификации как железа, так и организации сети в то время в паблике я не находил, вероятно проприетарные.
Можно (но не нужно) пойти простым, очевидным путём. Подключить какой-нибудь сервис DNS Failover (и верить, что не упадёт он).Взять и продублировать всю инфраструктуру на два ДЦ, настроить репликацию и мириться с тем, что либо данные в базе будут неактуальными, либо всё будет тормозить.
Хорошая экосистема серверов обычно требует того, чтобы сисадмин или девопс регулярно следили за новостями ДЦ и своевременно работали с возникающими проблемами.
Админы в самых разных ДЦ имеют неприятную особенность спокойно относиться к перебоям в работе локальных сетей. Перезагрузить свитч (или что там у них) - легко и в любое время. Аплинк - это "святое", а локалка время от времени преподносит неожиданности.
Если ОП реализует схему с пика, а потом у него отвалится мастер DB, возможны интересные последствия. В зависимости от того что там установлено и как настроено, приложение может нагадить в реплику, после поднятия первого мастера, мастер-мастер не осилит восстановление консистентности и всё может так хитро завернуться, что дорогой ОПу сервер ляжет не на полчаса, а, при неплохих объемах данных в DB, на целый день.
Уж лучше бы ему без всяких балансеров, один монолит на одном хорошем сервере вместе с DB, и по желанию, реплику DB рядом на сервере послабее и также на более дешевом сервере временную копию приложения, которая в случает падения основного сервера будет в аварийном режиме работать с репликой. Да и те не пригодятся скорее всего.
Вобщем, если хочется надёжности, нужно учитывать нестабильность локальных сетей в ДЦ.
С такими ценами выгоднее напрямую продавать.
Легко недооценить насколько сильный корпоративный монопольный игрок может сожрать рынок.
Если покупатели рекламы теперь смогут покупать показы через Яндекс у других владельцев площадок по условному 1 рублю, то зачем им возвращаться к вам и покупать за 10 условных рублей?
Пока лавина покупателей рекламы еще не вся перетекла в панель управления от Яндекса. Но понемногу текут, пробуют интерфейс, нарабатывают кейсы. А вы им в этом активно помогаете.
Как только рекламодатели привыкнут к интерфейсу, вернуть их в прямой закуп будет сложно.
Верный выбор в пользу свободы и доходов - никогда не продавать рекламу в TG через Яндекс.
Обычно сайты бывают недоступны не по причине отключений в качественном датацентре.
Если у ваших серверов по 2 блока питания, диски с приложением в зеркальном рейде, в коде нет критических ошибок и девопс не ошибся в деплое, то основная причина падений - это DDOS.
Я как-то заморачивался с резервными каналами, по две сетевые карты на разные аплинки в каждом сервере. Ни разу не пригодилось. И не слышал, чтобы кому-то пригодилось.
Зато от DDOS-а все постоянно лежат.Разнесете точки отказа - станет сложнее их защищать. Поэтому ассеты иногда целесообразно раздавать с помощью геоднс, а приложение лучше держать в одном ДЦ.
В остальном выше верно написано. Разве что я не за AWS, пусть девопс делает руками на железе (и документирует). На AWS при хорошей посещаемости выходит дороговато. Да и вендор лок до добра не доводит. Если поменяются тарифы/условия/санкции/блокировки и придется срочно переезжать, то намного легче сделать это с уже настроенным на своё железо деплоем.
Такой тренд наблюдается во всём мире.
Вы верно сравнили происходящее с глобальной сменой эпох.
Происходит чудовищное по масштабам уничтожение наследия миллиардов людей, оставленного в интернете "прошлого".
Десятки миллионов из тех людей были объективно талантливы и создали творения, не уступающие в культурной важности разнообразным более известным Монам Лизам.
Подобно глобальному вымиранию видов, сейчас по всему миру исчезают миллионы авторских сайтов.
А творения молодежи сразу после создания смываются в сливы бесконечных лент соцсетей и мессенджеров, часто не существуя дольше нескольких дней.
В мире происходит не только и не столько экономический кризис.
Кризис культурный для меня в сотни раз страшнее.
В исторических произведениях люди сражались и умирали за библиотеки. Сейчас они обезболены экранами своих устройств. Жизнь без мыслей, без боли, без будущего и без настоящего, не подмененного, прошлого длиннее нескольких дней. Эта антиутопия уже наступила. Разве до денег сейчас?
P.S. Задонатьте интернетархиву, ребята. Это один из немногих осколков наследия, что у нас есть.
