«Тушить» ли сервера, если «загорелся» смоук тест датацентра?

    Что бы вы почувствовали, если в один прекрасный летний день дата-центр с вашим оборудованием стал бы выглядеть вот так?



    Всем привет! Меня зовут Дмитрий Самсонов, я работаю ведущим системным администратором в «Одноклассниках». На фотографии один из четырёх дата-центров, где установлено оборудование, обслуживающее наш проект. За этими стенами находится около 4 тыс. единиц техники: серверы, система хранения данных, сетевое оборудование и т.д. — почти ⅓ всего нашего оборудования.
    Большинство серверов — это Linux. Есть и несколько десятков серверов на Windows (MS SQL) — наше наследие, от которого мы на протяжении многих лет планомерно отказываемся.
    Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.

    Отрицание


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

    Гнев


    Пытались ли вы когда-нибудь узнать у пожарных, в каком именно месте на крыше произошёл пожар, или самому попасть на горящую крышу, чтобы оценить ситуацию? Какой будет степень доверия к информации, полученной через пять человек?

    14:50. Поступила информация, что огонь подбирается к системе охлаждения. Но дойдёт ли? Дежурный системный администратор выводит внешний трафик с фронтов этого дата-центра.
    На данный момент фронты всех наших сервисов продублированы в трёх дата-центрах, используется балансировка на уровне DNS, что позволяет убрать адреса одного дата-центра из DNS, оградив тем самым пользователей от потенциальных проблем с доступом к сервисам. В том случае, если проблемы в дата-центре уже произошли, он выходит из ротации автоматически. Подробнее можно почитать тут: Балансировка нагрузки и отказоустойчивость в «Одноклассниках».

    На нас пожар пока никак не повлиял — ни пользователи, ни оборудование не пострадали. Авария ли это? Первый раздел документа «План действий при аварии» даёт определение понятию «Авария», а заканчивается раздел так:
    «Если есть сомнения, авария или нет, то это авария!»

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

    Торг


    15:01. Начинаем отключать сервера, которые не завязаны на продакшен.
    15:03. Корректно выключаем все зарезервированные сервисы.
    Сюда входят не только фронты (на которые к этому моменту пользователи уже не заходят) и их вспомогательные сервисы (бизнес-логика, кеши и т.д.), но и различные базы данных с replication factor 2 и более (Cassandra, хранилище бинарных данных, холодное хранилище, NewSQL и проч.).
    15:06. Поступила информация, что пожар угрожает одному из залов дата-центра. В этом зале у нас нет оборудования, но то, что огонь может перекинуться с крыши, на залы, сильно меняет картину происходящего.
    (Позже выяснилось, что физической угрозы для зала не было, так как он герметично изолирован от крыши. Угроза была только для системы охлаждения этого зала.)
    15:07. Разрешаем выполнение команд на серверах в ускоренном режиме без дополнительных проверок (без нашего любимого калькулятора).
    15:08. Температура в залах в пределах нормы.
    15:12. Зафиксировано повышение температуры в залах.
    15:13. Больше половины серверов в дата-центре выключены. Продолжаем.
    15:16. Принято решение о выключении всего оборудования.
    15:21. Начинаем отключать питание на stateless-серверах без корректного выключения приложения и операционки.
    15:23. Выделяется группа ответственных за MS SQL (их мало, зависимость сервисов от них не велика, но процедура восстановления работоспособности занимает больше времени и она сложнее чем, например, у Cassandra).

    Депрессия


    15:25. Поступила информация о выключении питания в четырёх залах из 16 (№6, 7, 8, 9). В 7-м и 8-м залах находится наше оборудование. Ещё о двух наших залах (№1 и 3) информации нет.
    Обычно при пожарах электропитание сразу отключают, но в данном случае, благодаря скоординированной работе пожарных и технического персонала дата-центра, его выключали не везде и не сразу, а по необходимости.
    (Позже выяснилось, что питание в залах 8 и 9 не отключалось.)
    15:28. Начинаем разворачивать базы MS SQL из бекапов в других дата-центрах.
    Сколько времени потребуется на это? Хватит ли пропускной способности сети на всём маршруте?
    15:37. Зафиксировано отключение некоторых участков сети.
    Менеджмент и продакшен-сеть изолированы друг от друга физически. Если продакшен-сеть доступна, то вы можете зайти на сервер, остановить приложение и выключить OS. Если же недоступна, то можно зайти через IPMI, остановить приложение и выключить OS. Если нет ни одной из сетей, то сделать вы ничего не можете. «Спасибо, кэп!», — подумаете вы.
    «Да и вообще, как-то много суматохи», — возможно также подумаете вы.
    Всё дело в том, что сервера даже без пожара генерируют огромное количество тепла. Точнее, когда есть охлаждение, они генерируют тепло, а когда его нет, то они создают адское пекло, которое в лучшем случае расплавит часть оборудования и отключит другую часть, а в худшем… вызовет пожар внутри зала, который практически гарантированно уничтожит всё.



    15:39. Фиксируем проблемы с базой conf.
    База conf является бекендом для одноимённого сервиса, который используется всеми приложениями продакшена для оперативного изменения настроек. Без этой базы мы не можем управлять работой портала, но сам портал при этом работать может.

    15:41. Температурные датчики на Core сетевом оборудованим фиксируют показания близкие к предельно допустимым. Это коробочка, занимающая целую стойку и обеспечивающая работу всех сетей внутри дата-центра.



    15:42. Issue tracker и wiki недоступны, переключаемся на standby.
    Это не продакшен, но при аварии доступность любого knowledge base может быть критичной.
    15:50. Отключилась одна из систем мониторинга.
    Их несколько, и они отвечают за разные аспекты работы сервисов. Часть из них настроены на автономную работу внутри каждого дата-центра (то есть они мониторят только свой дата-центр), другие состоят из распределённых компонентов, прозрачно переживающих потерю любого дата-центра.
    В данном случае перестала работать система обнаружения аномалий показателей бизнес-логики, которая работает в режиме master-standby. Переключились на standby.

    Принятие


    15:51. Через IPMI выключили без корректного завершения работы все сервера, кроме MS SQL.
    Готовы ли вы к массовому управлению серверами через IPMI в случае необходимости?


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

    16:13. Поступила информация о том, что на крыше лопнули фреоновые трубки от кондиционеров — это отложит запуск дата-центра после устранения пожара.
    16:19. По данным, полученным от технического персонала дата-центра, прекратилось повышение температуры в залах.
    17:10. Восстановили работу базы conf. Теперь можем поменять настройки приложений.
    Почему это так важно, если всё отказоустойчиво и работает даже без одного дата-центра?
    Во-первых, отказоустойчиво не всё. Есть различные второстепенные сервисы, которые пока недостаточно хорошо переживают отказ дата-центра, и есть базы в режиме master-standby. Возможность управлять настройками позволяет сделать всё необходимое, чтобы даже в сложных условиях минимизировать влияние последствий аварии на пользователей.
    Во-вторых, стало понятно, что в ближайшие часы работа дата-центра полностью не восстановится, поэтому необходимо было принять меры, чтобы долговременная недоступность реплик не привела к дополнительным неприятностям вроде переполнения дисков в оставшихся дата-центрах.
    17:29. Время пиццы! У нас работают люди, а не роботы.



    Реабилитация


    18:02. В залах №№8 (наш), 9, 10 и 11 стабилизировалась температура. В одном из тех, что остаются отключенными (№7), находится наше оборудование, и температура там продолжает расти.
    18:31. Дали добро на запуск оборудования в залах №№1 и 3 — эти залы пожар не затронул.


    На текущий момент проводится запуск серверов в залах №№1, 3, 8, начиная с самых критичных. Проверяется корректность работы всех запущенных сервисов. По-прежнему есть проблемы с залом №7.


    18:44. Технический персонал дата-центра обнаружил, что в зале №7 (где стоит только наше оборудование) многие серверы не выключены. По нашим данным, там остаются включенными 26 серверов. После повторной проверки обнаруживаем 58 серверов.
    20:18. Технический персонал дата-центра продувает воздух в зале без кондиционеров через мобильные воздуховоды, проложенные через коридоры.
    23:08. Отпустили первого админа домой. Кто-то должен ночью поспать, чтобы завтра продолжить работы. Далее отпускаем ещё часть админов и разработчиков.
    02:56. Запустили всё, что можно было запустить. Делаем большую проверку всех сервисов автотестами.



    03:02. Кондиционирование в последнем, 7-м зале восстановлено.
    03:36. Завели фронты в дата-центре в ротацию в DNS. С этого момента начинает приходить пользовательский трафик.
    Распускаем большую часть команды администраторов по домам. Но несколько человек оставляем.
    Небольшой FAQ:
    Q: Что происходило с 18:31 до 02:56?
    A: Следуя «Плану действий при аварии», мы запускаем все сервисы, начиная с самых важных. При этом координатор в чате выдаёт сервис свободному администратору, который проверяет, запустились ли OS и приложение, нет ли ошибок, в норме ли показатели. После завершения запуска он сообщает в чат, что свободен, и получает от координатора новый сервис.
    Процесс дополнительно тормозится отказавшим железом. Даже если остановка OS и выключение серверов прошли корректно, часть серверов не возвращается из-за внезапно отказавших дисков, памяти, шасси. При потере электропитания процент отказов увеличивается.
    Q: Почему нельзя просто запустить всё разом, а потом чинить то, что вылезет в мониторинге?
    A: Все надо делать постепенно, потому что между сервисами есть зависимости. А проверять всё следует сразу, не дожидаясь мониторинга — потому что с проблемами лучше разобраться сразу, не ждать их усугубления.

    7:40. Последний админ (координатор) ушёл спать. Работы первого дня завершены.
    8:09. Первые разработчики, инженеры в дата-центрах и администраторы (включая нового координатора) приступили к восстановительным работам.
    09:37. Приступили к поднятию зала №7 (последнего).
    Параллельно продолжаем восстанавливать то, что не дочинили в других залах: замена дисков/памяти/серверов, починка всего, что «горит» в мониторинге, обратное переключение ролей в схемах master-standby и прочие мелочи, которых тем не менее достаточно много.
    17:08. Разрешаем все штатные работы с продакшеном.
    21:45. Работы второго дня завершены.
    09:45. Сегодня пятница. В мониторинге по-прежнему довольно много мелких проблем. Впереди выходные, всем хочется отдохнуть. Продолжаем массово чинить всё, что можно. Штатные админские задачи, которые можно было отложить, отложены. Координатор новый.
    15:40. Внезапно рестартанулась половина стека Core сетевого оборудования в ДРУГОМ дата-центре. Вывели из ротации фронты для минимизации рисков. Эффекта для пользователей нет. Позже выяснилось, что это было сбойное шасси. Координатор работает с починкой сразу двух аварий.
    17:17. Работа сети в другом дата-центре восстановлена, всё проверено. Дата-центр заведён в ротацию.
    18:29. Работы третьего дня и в целом восстановление после аварии завершено.

    Послесловие


    04.04.2013 г., в день 404-й ошибки, «Одноклассники» пережили крупнейшую аварию —в течение трёх суток портал полностью или частично был недоступен. На протяжении всего этого времени более 100 человек из разных городов, из разных компаний (ещё раз большое спасибо!), удалённо и непосредственно в дата-центрах, в ручном режиме и в автоматическом чинили тысячи серверов.
    Мы сделали выводы. Чтобы подобное не повторилось, мы провели и продолжаем проводить по сей день обширные работы.

    В чём основные отличия нынешней аварии от 404?

    • У нас появился «План действий при аварии». Раз в квартал мы проводим учения — разыгрываем аварийную ситуацию, которую группа администраторов (все по очереди) должна устранить, используя «План действий при аварии». Ведущие системные администраторы по очереди отрабатывают роль координатора.
    • Ежеквартально в тестовом режиме изолируем дата-центры (все по очереди) по сети LAN и WAN, что позволяет своевременно выявлять узкие места.
    • Меньше битых дисков, потому что мы ужесточили нормативы: меньше наработка часов, строже пороговые значения для S.M.A.R.T.,
    • Полностью отказались от BerkeleyDB — старой и нестабильной базы данных, требовавшей много времени на восстановление после рестарта сервера.
    • Сократили количество серверов с MS SQL и уменьшили зависимость от оставшихся.
    • У нас появилось своё облако — one-cloud, куда мы уже в течение двух лет активно мигрируем все сервисы. Облако значительно упрощает весь цикл работы с приложением, а в случае аварии даёт такие уникальные инструменты, как:
      • корректная остановка всех приложений в один клик;
      • простая миграция приложений со сбойных серверов;
      • автоматический ранжированный (в порядке приоритета сервисов) запуск целого дата-центра.

    Авария, описанная в данной статье, стала крупнейшей со дня 404-й. Конечно, не всё шло гладко. Например, во время недоступности дата-центра-погорельца в другом дата-центре вылетел диск на одном из серверов, то есть осталась доступна только одна из трёх реплик в Cassandra-кластере, из-за чего 4,2% пользователей мобильных приложений не могли залогиниться. При этом уже подключенные пользователи продолжали работать. Всего по результатам аварии выявлено более 30 проблем — от банальных багов до недостатков архитектуры сервисов.

    Но самое главное отличие нынешней аварии от 404-й в том, что пока мы устраняли последствия пожара, пользователи по-прежнему переписывались и делали видеозвонки в Tamtam, играли в игры, слушали музыку, дарили друг другу подарочки, смотрели видео, сериалы и телеканалы в ОК, а также стримили в OK Live.

    А как проходят ваши аварии?
    Одноклассники
    Делимся экспертизой

    Комментарии 47

      –17
      (off-topic про тамтам)
        –17
        (off-topic про тамтам, еще пара слов)
          –16
          (и off-topic по вопросу, вынесенному в заголовок).
        –19
        Русское слово «загорелся» в кавычках, а «перевод» английского «смоук» на русскую раскладку оставили без перевода.
        Даже как итишник с не одним десятком лет опыта и то с первого раза не врубился, че это за смоук-чпоук-слоупок тест такой.
          +5
          А чем обусловлена балансировка на уровне DNS? Ведь если нужно будет очень срочно убрать трафик с какой-то из локаций, то все равно он уйдет только через TTL-секунд.

          Анонсируя ebgp какой-то один VIP, прописываемый в DNS — это не так эффективно? Там и анонс убрать намного быстрее получится.

          Возможно, я заблуждаюсь и говорю немного не о том, но все-таки хотелось бы услышать о таком решении.
          0
          Например, во время недоступности дата-центра-погорельца в другом дата-центре вылетел диск на одном из серверов, то есть осталась доступна только одна из трёх реплик в Cassandra-кластере

          А можно подробностей, как так вышло что один сбойный диск положил реплику?
            0
            Вполне возможно что при вылете одного из диска в массиве, скорость всего массива сильно падает и не справляется с нагрузкой, забивается очередь реплики и она отваливается. Так, чисто предположение.
              +4
              Данные в кассандре и так хранятся в 3 экземплярах (не считая бекапов), поэтому тут мы не используем массивы.
                0
                Это всё объясняет.
                  +1
                  Но тогда имеет смысл, например, удвоить или утроить число реплик, сделав по две (или три) на каждый ДЦ (не знаком с архитектурой Cassandra)?
                  Кажется, данный случай на это намекает
                    +2
                    Такое решение было бы экономически неэффективным. В кассандрах сейчас хранится более 100PB данных в более чем 1000 нод. По такой схеме нам бы пришлось доставить еще грубо 1 или 2 тысячи нод.
                    Мы сейчас смотрим больше в сторону полной автоматизации замены сбойных нод — что позволит снизить время недоступности оных изза отказа железа. Временная репликация тоже выглядит многообещающе, будем пробовать внедрять.
                    Конкретно же с этим случаем, отказавший сервис не должен был влиять на доступность логина, это было ошибочное поведение.
                    Сервисы, связанные с доступностью логина и другими критическими функциями резервируются у нас обычно с RF=5 вместо 3.
                +2
                Потому что на этой реплике один диск с данными.
              +3
              Итак, 5 июня 2019 г. в 14:35 инженеры одного из наших дата-центров сообщили о пожарной тревоге.

              Везет вам, вас предупредили
              А я об инциденте узнал в 15.15 постфактум от заббикса. Дозвониться до саппорта было невозможно, поэтому о причинах я вообще узнал из новостей стороннего телекомовского чатика куда более удачливый коллега скинул информацию.
              Вот так вот читаешь на сайтах про всякие Tier III спецификации, надежность и резервирование, а в реале при аварии саппорт даже примерные сроки восстановления сказать не может
                +5
                В каждом нашем дата-центре каждый день работают наши инженеры. В здании сработала пожарная тревога, они её услышали и рассказали это нам.
                Были ли какие-то проблемы со службой поддержки мне не известно, но судя по вот этой статье служба поддержки тоже пострадала от пожара:
                Потеря каналов связи из-за пожара внутри компании и с клиентами усугубила ситуацию. После пожара Dataline задублировала все каналы связи и внутренние сервисы в своих дата-центрах Nord и Ost.
                  +1
                  Всё зависит от того, есть ли под рукой необходимые запчасти и специалисты. 100% надёжности ни один Tier не подразумевает, и вряд ли даже гарантирует соблюдение своих нормативов по срокам восстановления особенно если ответственность по SLA грамотный юрист оценил в копейки.
                  +1
                  почему бы не автоматизировать аварийное последовательно отключение \включение оборудования?
                    +3
                    Это уже сделано в нашем облаке, куда мы активно мигрируем весь наш продакшен. В конце статьи об этом написано.
                    +1
                    А что с MS SQL не так? Он же обеспечивает высокую доступность из коробки. Причём буквально бесплатно.
                      +5
                      Мы используем MS SQL уже 13 лет, начиная с первых версий сайта. За это время мы вкусили всего его прелести (которых безусловно не мало) и недостатки. Примерно столько же лет мы планомерно переходим на Open Source решения (даже вебсервера в первые годы жизни проекта работали на решениях Microsoft). Что касается баз данных, то для критичных систем мы стараемся использовать NoSQL решения и собственные разработки.
                        –8
                        импортозамещение, подозреваю. а дальше уже все остальное.
                        +1
                        Странный вопрос, выключать ли серваки при пожарной тревоге, помоему при любом раскладе нужно выключать серваки, даже если пожара именно в ваших залах нету то сеть-электричество может отвалиться палюбому. Так что лучше пусть пользоваатели 1-2 часа поноют, чем потом вычищать глюки в базах
                          +1
                          Удовлетворённость пользователей для нас очень важна, так же как и сохранность данных. Однако, в данном случае угрозы потери данных не было, поэтому мы делали всё, что бы и пользователи не пострадали.
                          0
                          15:16. Принято решение о выключении всего оборудования.
                          15:21. Начинаем отключать питание на stateless-серверах без корректного выключения приложения и операционки.
                          Пяти минут не хватило, чтобы зайти по SSH на каждый из серверов и ввести в терминал
                           /etc/init.d/nginx stop && poweroff
                          или что-то подобное?
                            0
                            А как же порядок выключения? Отключишь так первым сервер, через который идёт ssh-трафик — и как остальные тогда выключать?
                              0
                              Зачем направлять весь SSH-трафик с доверенных IP-адресов через один сервер?
                                +1
                                Ещё лучше. Нарушил порядок выключения — не смог выключить часть серверов… А задача же в выключении на скорость состоит, так?
                                  0
                                  Файрволлы, роутеры и свитчи надо выключать последними. И на них нет столь ценной и уязвимой информации, как на серверах.
                              +1
                              Во-первых, нужно было собрать список серверов подходящих под нужные критерии.
                              Во-вторых, в этот момент мы продолжали выключать и другие сервера, поэтому свободных рук моментально не было доступно.
                              Остановка приложения и корректное выключение операционки для этих серверов на этом этапе уже не делалось. Просто выключали питание на всех серверах черех IPMI. Для таких задач мы используем заранее подготовленный многопоточный скрипт.
                                0
                                Для таких задач мы используем заранее подготовленный многопоточный скрипт.
                                Скрипт — это правильно: понятно, что вручную не успеть. (Скрипт полезен для корректного завершения. Для отключения электричества достаточно рубильника.)

                                нужно было собрать список серверов подходящих под нужные критерии.
                                свободных рук моментально не было доступно
                                То есть заранее подготовленный многопоточный скрипт в те времена ещё не использовали?
                                  +1
                                  Скрипт о котором идёт речь в предыдущем комментарии получает на вход список серверов и далее может произвести с ними какие-то действия по IPMI.
                                  Список серверов готовится на основании CMDB другими утилитами.
                                  В тот момент авария была в самом разгаре, все занимались выключением серверов. Как только появился первый свободный администратор он занялся задачей выключения части серверов по IPMI. Отрывать кого-то от выключения серверов, что бы выключить другие сервера не имело никакого смысла. К тому же было известно, что ближайший человек освободится в течении считанных минут, а ситуация позволяла нам их ждать.
                              +2
                              Интересно так же узнать о физических причинах пожара. Сам с пожарами не сталкивался, в серверных где присутствовал установлена автоматическая система пожаротушения. Гореть со стороны кажется нечему, современные материалы достаточно огнеустойчивы.
                              Если отдельно выделено здание под датацентр, источников возгорания должно быть минимум. С легким задымлением понятно, даже светодиодные светильники могут при замыкании напустить дыма, не говоря о силовом, более мощном оборудовании. Но, в тех случаях, которые я наблюдал, на этом всё и заканчивалось, 15 минут на проветривание и всё. Поэтому и интересно, как пошло распространение и поддержание горения на таком уровне, что смогло повредить систему охлаждения. Ошибка проектировщиков, упустили что-то и применили устаревшие пожароопасные материалы?
                                +4
                                Там горела крыша ДЦ, ни в одном машзале пожара не было. http://www.tadviser.ru/index.php/Продукт: ЦОД_DataLine_Москва_Боровая,_7
                                  0
                                  Очень качественный обзор происшествия по существу. Вот, наверное, ключевой момент пожара. Если бы не деревянные элементы (без противопожарной пропитки вероятно), гореть было бы нечему. Дерево высыхает и становится пожароопасным.
                                  Часть проблем была связана с тем, что крыша дата-центра содержала деревянные элементы, хотя сама и была металлической, и имела сложную конструкцию. Теперь запущен технически сложный проект по созданию новой крыши с негорючими материалами
                                    0
                                    Противопожарная пропитка так себе средство www.youtube.com/watch?v=-ZdbpxHHQec
                                      0
                                      Как-раз показывает, что от небольших пожаров защищает, огнестойкость хоть в небольших пределах, но возрастает. На крыше все же не бензином поджигали, а небольшим источником тепла, немного огнестойкости и всё бы ограничилось задымлением.
                                      Аналогичные исследования есть для проводов и гофрорукавов. Есть самозатухающие, есть такие что хорошо поддерживают горение. Вероятно, загоревшийся провод передал горение дереву. К проводу и гофре тоже могут быть вопросы.
                                0
                                а можно ссылку на conf?
                                  +2
                                  Это внутренняя разработка. Про нее подробной информации не было в публичном пространстве, я рассказывал пару слайдов на техтрейне в прошлом году.
                                  Можно послушать например тут: youtu.be/zfmwd52VuQ0?t=2313
                                    0
                                    жаль что пропрайтори :-)
                                      0
                                      Лично мне, кажется вариант с хранением данных в Кассандре и подобных ему системах не оптимальным. Я понимаю, что Вы уже много лет сидите на Кассандре и менять её скорее всего не будете, но почему бы Вам не рассмотреть вариант как устроены базы данных в соцсети ВКонтакте? Зачем нужны такие громоздкие системы вроде Кассандры, если можно написать собственные маленькие движки(key-value) каждый из которых оптимизирован под КОНКРЕТНЫЙ тип данных, например chat-engine оптимизирован хранить групповые чаты и личные сообщения, движок logs хранит логи, движок meowdb хранит статистику и метрики, движок image хранит изображения, pmemcached — хранит кэш не только в памяти, но и на диске, targ2 — информация о таргетированой рекламе + поиск людей, групп, сообществ по конкретным данным, например пол, возраст, место проживания. Главная особенность, что команда разработчиков ВК много работы проводят над конкретно способами хранения КОНКРЕТНЫХ типов данных, а не просто так огромная база данных, хоть и имеет больше функций, но конкретно под тип данных не оптимизирована.
                                        +1
                                        Посылка, что мы используем кассандру как одну огромную БД ложна.
                                        Как раз недавно я рассказывал о нашем способе построения систем на основе C*.
                                        Видео про это с Joker 2019 можно посмотреть тут: www.youtube.com/watch?v=x9tvJjWCrr4
                                          0
                                          Я посмотрел доклад. Неплохо. Я смотрел почти все Ваши доклады и доклады Ваших конкурентов из ВКонтакте. И сравниваю структуры бэкенда двух крупнейших в Рунете соцсетей
                                    +4
                                    Спасибо за статью! Не могу сказать, что узнал много нового, но получил огромное эстетическое удовольствие. Чуствуется слог профессионального администратора, который знает, о чем говорит, как говорит и что делает. Кратко, лаконично, по существу ) Очень правильный человек на нужном месте в одноклассниках )
                                      +1
                                      Спасибо за приятные слова :)
                                        0
                                        Причем администратора, а не модного девопса )

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое