How to become an author
Search
Write a publication
Pull to refresh

Comments 37

Если вы пытаетесь тонко намекнуть что MS успела поменять архитектуру сети и инструментов развертывания, то, мне кажется, вы неправы. Все эти решения, похоже, были внедрены уже довольно давно.
Total votes 34: ↑30 and ↓4+26
Ну что вы, конечно же не успела еще. Но каким-то необъяснимым образом им всегда достаточно самого факта приобретения.
Total votes 62: ↑21 and ↓41-20
С неделю назад я заметил некоторые деградации в функциональности гитхаб: в частности, не работает поиск по коду в форках. Вот только не понятно, это последствие аварии или нет. Не работает до сих пор. Так что какие-то изменения всё же проводятся.
Total votes 1: ↑1 and ↓0+1

А он когда-то работал? Во всяком случае, года 2 точно поиск по коду в форках не работает.

Total votes 5: ↑5 and ↓0+5

Может это стало причиной что уволились(ли) люди, которые были в курсе как действовать в подобной ситуации, а поделиться в общую knowledge base не успели или уже не захотели. Это лишь догадки как может быть связано с поглощением MS.
Запасаемся попкорном и ждём проблем от продуктов/ RedHat...

Total votes 9: ↑8 and ↓1+7
>что MS успела поменять архитектуру сети и инструментов развертывания, то, мне кажется, вы неправы

Одно из двух: либо раньше github не умел переживать сплиты (что фантастично), либо таки кто-то поковырялся или специально подгадил.
Total votes 2: ↑0 and ↓2-2
UFO just landed and posted this here
Что-то мне сразу вспомнилось как AWS хостил свой Status Page у себя же. И когда пару лет назад AWS капитально упал вместе с ним слег и их Status Page.
Total votes 6: ↑6 and ↓0+6
Не слёг, а показывал, что всё в порядке. Т.к. список проблем хранился на S3, а сбой был в S3.
image
Total votes 10: ↑10 and ↓0+10
Это же типичный split brain? Получается что виноват тот, кто не предусмотрел что «плановые ремонтные работы» приведут к падению сети и не обеспечил резервный канал.
Total votes 10: ↑9 and ↓1+8
А ещё можно поговорить про выбор MySQL для HA-хранилища. Я вообще не знаю, как там устроено в MySQL, но в случае PostgreSQL я бы только поставил на шардирование, где выход из строя одного из шардов — это всего-лишь Х%-процентная потеря на запись.
Total votes 4: ↑3 and ↓1+2
Поцгрес точно так же далек от HA как и мускуль :)

Шардирование тут никак не помогло бы, потому что вылетел не какой-то один сервер, а весь ДЦ.
Собственно, тут есть два противоречивых требования — с одной стороны, избежать трансконтинентальной латенси и соблюдать строгую консистентность с другой стороны. Как ни крути, но всегда будет какое-то количество недоехавших до слейвов транзакций, которые так и не будут реплицированы в случае аварийной смены мастера. В принципе, есть та же Galera, можно было бы перевезти часть критичных к консистентности кластеров мускуля на нее; но опять же, это автоматом добавит RTT ко всем операциям записи.

Я б сказал, проблема тут вот в чем:
приложения на востоке, которые зависят от записи информации в западный кластер MySQL, в настоящее время не способны справиться с дополнительной задержкой из-за передачи большинства их вызовов БД туда и обратно

Сразу возникает вопрос — а зачем содержать ДЦ, в который нельзя полноценно переключиться? Надо либо допиливать эти приложения, либо сделать так, чтобы приложения бежали рядом со своими данными: переключился мастер базы — балансеры переключили юзерский трафик на новое место.
Total votes 9: ↑9 and ↓0+9
Шардирование тут никак не помогло, потому что вылетел не какой-то один сервер, а весь ДЦ.

Мм, а почему нельзя ключ шарда привязать к региону. Вроде бы в этом случае просто пропадет запись только в один из ДЦ, к которому был привязан данный регион.
This comment wasn’t rated yet0
Можно, только это будет значить, что записи в этот шард пойдут на другое побережье, чему местные программы не обучены
Total votes 2: ↑2 and ↓0+2
Извини, я не придераюсь, просто хочу разобраться)

Вот у нас есть ключ шардирования, который делит пользователей на:
  • User1- East
  • User2- East
  • User3- East
  • User4- West
  • User5- West


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

Пусть упал East DC. В этой ситуации пользователи User1, User2 и User3 не могут ничего записывать. А пользователи User4 и User5 — могут.

Не очень понимаю, откуда тут появится запись в шард на другое побережье? Вижу в этом примере только чтение из реплики данных пользователей User1, User2, User3 из другого побережья.
This comment wasn’t rated yet0

Ну, навскидку можно предположить, что помимо базового функционала гита, основное «мясо» гитхаба — это как раз взаимодействие между пользователями, так что я бы предположил, что по юзерам их данные шардируются плоховато. Конечно, если это не так, то да, шардирование тут бы уполовинило серьёзность инцидента, но никак не решила б его целиком, а заодно добавила бы задержки на все операции, которые касаются взаимодействия между разными шардами. Да и в целом, шардирование оно про масштабирование, а не доступность.

Total votes 1: ↑1 and ↓0+1
Может причина в том, что какие-то ключевые специалисты ушли из GitHub?
Total votes 1: ↑1 and ↓0+1
Виноват тот, кто построил такую географически-распределённую архитектуру, которая не выполняет целей, поставленных при её создании.

Недостаточно заинсталлить «Оркестратор», или какие то другие продукты с звучащими брендами, недостаточно произносить фразы об умных практиках.
«Мы не имели опыта падения датацентров целиком» — удивительно, то есть для Хабра нет тестовой системы, и архитектурные решения не проходят тестирования? Это же элементарные вещи, как можно не проверить работоспособность системы, и что вообще произойдёт, если в тестовой системе отключить один кластер.

В команду нужен человек, который в состоянии рисовать на бумажке алгоритмы функционирования архитектуры «что будет, если», имеющий желание это делать, и имеющий полномочия для изменений архитектуры.
Total votes 2: ↑1 and ↓10
Ой, опечатался, не «у Хабра», а «у GitHub-а», конечно
Total votes 1: ↑0 and ↓1-1
Странно это все. Без всяких оркестраторов у них был бы даунтайм 43 секунды. Смысл в этих наворотах, если они не выполняют единственную свою задачу? Было ли тестирование такого сценария? Почему при небольшом рассогласовании данных нет другого механизма, кроме как восстановление из бэкапа?
Total votes 13: ↑13 and ↓0+13
Это напомнило проблему месячной давности на Selectel. Отказ коммутатора вызвал выход кластера дисков из сбалансированного состояния. Сеть довольно скоро заработала, однако перезапуск кластера и балансировка данных заняли 12 часов, всё это время виртуалки клиентов не работали. Строим более сложные системы вроде как для более высокой надёжности, однако последствия выхода их из строя порой оказываются даже более серьёзными.
Total votes 10: ↑10 and ↓0+10
Подозреваю, что без всех этих наворотов у них была бы куча даунтаймов по 43 секунды и даже больше. А так пользователи просто не замечают проблем — при проблемах все продолжает работать. Другое дело что да, когда проблема возникает уровнем выше, последствия серьезнее.
Total votes 1: ↑1 and ↓0+1

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

Total votes 1: ↑1 and ↓0+1

К чему вы это сказали-то?
Что кто-то должен был подумать и решить "давайте падать каждый день по минуте, норм"? Так нет, никакой вменяемый руководитель такого не скажет.
Или что для гитхаба не критичны падения по 43 секунды? Критичны. Они платный сервис предоставляют, и не очень дешевый.

This comment wasn’t rated yet0
UFO just landed and posted this here
Я подумал то же самое 21 октября, когда создал проект и не увидел его созданым. Очень знакомая по Azure картина вечной борьбы с кешами.
This comment wasn’t rated yet0
Жизнь всегда немного сложнее самых смелых предположений, поэтому собственно
Эта работа включает умышленное внесение неисправностей и применение инструментов хаос-инжиниринга.
Total votes 1: ↑1 and ↓0+1
Радует, что GitHub не отмолчался в духе «We were experiencing techincal issues», а подробно расписал что случилось и как исправили. Все бы так делали.
Total votes 12: ↑12 and ↓0+12
Странно, что столь простой сценарий (фактически — выход из строя одного канала связи) обрушил всё так сильно. Т.е. не смотря на все эти «облака» и «резервирование» прямо сейчас в каком-нибудь дата-центре может навернуться один-единственный конденсатор в каком-то девайсе и это может обрушить инфраструктуру размером с GitHub.
Total votes 4: ↑4 and ↓0+4
В такие моменты я почему-то всегда думаю о людях, которым приходится срочно, быстро и долго(как для рабочего дня) это все фиксить.
Total votes 6: ↑6 and ↓0+6
люблю истории где 99,999% надежность декларируется, но ни кто даже не проигрывает сценарии на практике, против которых вбухиваются огромные деньги в отказоустойчивость
Total votes 6: ↑5 and ↓1+4
Когда в восточном ДЦ между двумя узлами кратковременно пропала связь, orchestrator решил, что «шеф, всё пропало, упал primary кластер БД» — и сделал ведущим западный кластер (чего никто не ожидал, в том числе приложения). В принципе, правильно сделал, но не в этом случае. Мораль проста — не стоит полагаться на дефолтные настройки.
Total votes 2: ↑2 and ↓0+2
Тот кто продался тот ничего не приобрел…
Total votes 2: ↑2 and ↓0+2
Sign up to leave a comment.

Articles

Show the best of all time
Unlock dark mode

Your account

Sections

Information

Services

Support
© 2006–2024, Habr