Как мы убили себя в один клик, размещая сайт и биллинг на геокластере или ещё раз поговорим об избыточности

    Да, я тоже бываю дебилом. Но такого я от себя не ожидал. Вроде бы «не первый год замужем». Вроде бы читал кучу умных статей об отказоустойчивости, избыточности и т.п., что-то разумное когда-то написал даже сам тут. Свыше 10 лет являюсь CEO хостинг-провайдера работающего под брэндом ua-hosting.company и предоставляющего услуги хостинга и аренды серверов в Нидерландах, США, а буквально неделю назад и в Великобритании (не спрашивайте, почему название ua, ответ можете найти в нашей автобиографической статье), предоставляем клиентам решения различной степени сложности, иногда такой, что даже сами затрудняемся разобраться в том, что сотворили.

    Но блин… Сегодня я превзошёл сам себя. Мы сами себе полностью снесли сайт и биллинг, со всеми транзакциями, данными клиентов об услугах и прочим и в этом виноват был я, я сам сказал «удаляй». Некоторые из Вас уже заметили это. Это случилось сегодня, в пятницу в 11:20 по восточному североамериканскому времени (EST). Причём наш сайт и биллинг размещены были не на одном сервере, и даже не в облаке, мы ушли из облака дата-центра 2 месяца назад в пользу нашего собственного решения. Всё это размещалось на отказоустойчивом гео-кластере из двух виртуальных серверов — нашего нового продукта, VPS (KVM) c выделенными накопителями, НЕЗАВИСИМЫХ VPS, которые располагались на двух континентах — в Европе и в США. Один в Амстердаме, а другой в Манассасе, под Вашингтоном, тем, что D.C. В двух надёжнейших дата-центрах. Контент на которых постоянно и в реальном времени дублировался, а отказоустойчивость основана на обычном кластере DNS, запросы могли приходить на любой из серверов, любой выполнял роль MASTER, и в случае недоступности брал на себя задачи второго.

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

    Это можем быть мы сами, мы, если мы — идиоты. В мире существует только две безграничных вещи — Вселенная и человеческая тупость, и если первое спорно, то второе стало очевидным.

    Я всегда придерживался принципа здравого резервирования, я не из тех людей, кто будет кричать «я теряю $1000 за час простоя», но при этом плачу $15 за всю свою инфраструктуру. Нет, я конечно не теряю столько. Хотя, возможно, иногда и теряю. Большинство идиотов, кричащих это, даже не задумываются о том, что порой простой в секунду может стоить $1000, $10 000 или даже миллиона долларов прибыли в долгосрочной перспективе. Каким образом? Очень просто, в эту секунду может зайти клиент, который сделает свой первый заказ, а в перспективе принесёт Вам эти миллионы долларов, ведь Вы всегда имеете возможность доказать ему свою уникальность и заслужить его рекомендации. И если он увидит ошибку 504 или «извините, но сервер сейчас недоступен», сделка может и не состояться. У нас такое случалось, нет, не 504 ошибка во время захода важного посетителя, а первое. Чисто по вселенской случайности я оказывался в нужном месте и в нужное время, когда на наш сайт заходили крупные заказчики, такие как Дмитрий Суханов, создатель «Кинопоиск», хотя это и не очень удачный пример, ведь он проработал с нами только 2 года, пока его не выкупил Яндекс за $60 млн или сколько там. Так что миллионы тут скорее получил Дмитрий, а не мы, но мы были рады сотрудничать со столь интересным и полезным проектом и это, в свою очередь, сделало нам рекламу и обеспечило много новых и довольных заказчиков.

    В общем, к чему я это всё. Убытки и нужную избыточность нужно оценивать здраво. Хотя и существует риск потерять миллион+ долларов, но нужно смотреть на вероятность такого события. Скорее всего, если бы Дмитрий увидел 1 раз ошибку 504 ничего критичного не произошло бы, и он вернулся к нам ещё раз. Почему? В то время мы, наверное, были одними из немногих, кто мог предложить коннективность 1+ Гбит / с по Украине с высоким качеством и минимальной latency за недорого, что было крайне важно для их ресурса в то время, чтоб обеспечить качественный доступ украинской аудитории к порталу, так как зарубежный трафик был низкого качества и всё ещё дорогим. Так что важно обеспечивать ещё и уникальность решения, тогда аптайм Вам не будет сильно критичным. А так как мы уникальны — мы вполне можем допустить для себя (даже сейчас), имея тысячи клиентов серверов, простой в несколько часов или даже более. Нам не нужны мегаотказоустойчивые облака, обеспечивающие 99,9999% аптайм за уйму денег, ибо даже они падают, а если падают, то как показала практика — очень надолго, так как проблема, вызвавшая недоступность, вероятно, нерядовая. И они не помогут в случае уязвимости. Никакак не помогут.

    Вот и мы строили своё решение для себя очень просто. Взяли две VPS (KVM) на нодах Dell R730xd, такие же VPS (KVM), как предлагаем клиентам, ведь это наш изначальный принцип — давать людям то, чем пользуемся сами:

    VPS (KVM) — 2 x Intel Dodeca-Core Xeon E5-2650 v4 (24 Cores) / 40GB / 4х240GB SSD RAID10 / Datatraffic — 40TB — от $99 / месяц, и можно получить скидку 30% на первый платёж, если найти промо-код в нашей рекламной статье.

    Одну в Нидерландах, а другую в США. Да, на этих нодах, помимо нашего сайта и биллинга, ещё по 2 реальных клиента, которые могут оказывать влияние на работу нашего сайта в теории и не могут сделать это на практике. Почему — написано в рекламной статье, вдаваться здесь в подробности второй раз не буду. Сейчас речь не об этом. В общем решение не хуже выделенных серверов начального уровня и может обрабатывать очень большую нагрузку.

    Помимо прочего оно отказоустойчиво, данные постоянно реплицируются в реальном времени. И в случае недоступности одного сервера, роль MASTER возьмет второй. В идеале можно сделать ещё так, что трафик с американского континента будет обрабатывать американский сервер, а с Европы, РФ и Азии — сервер в Нидерландах.

    Серверы мы подвязали в свой аккаунт в нашем биллинге WHMCS, публичного лицензионного продукта, но адаптированного под нас, которым пользуется множество хостинг-провайдеров по всему миру, в том числе и мы, так как писать собственную систему учёта — откровенный дебилизм (в нашем случае). В особенности в тех случаях, когда нужная функция реализуется написанием собственного модуля к существующему биллингу, что повышает Вашу отказоусточивость, так как снижает риск наличия критичных уязвимостей. Ведь в одиночку или даже небольшой командой Вы не сможете написать более надёжную систему, нежели существующая, которая писалась годами туевой кучей разрабов, где уже выпилены тысячи багов и за которую теперь разработчики просят всего лишь от $30 / месяц за лицензию и получают миллионы долларов в год, которые могут расходоваться в том числе на дальнейшие улучшения.

    К слову о критических уязвимостях, недавно наш программист допустил ошибку при написании одного из сервисных модулей, который имел доступ к базе биллинга только на чтение, которую обнаружил независимый пентестер и обратился к нам с предложением заплатить $550 за найденный баг, так как это была уязвимость SQL-injection:

    SQL-injection находиться в топ 10 OWASP, я вам написал про сумму в $550, это минимальная сумма, поскольку страдает БД, тем самым возможна компрометация данных пользователей.

    Но некоторые суммы доходят до $10 000 в качестве вознаграждения, как пример в случае vk.com.

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

    Аудит безопасности всего ресурса, а это проверка по следующим параметрам, и наш отчет по окончанию аудита, включает:

    •A1 Внедрение кода
    •A2 Некорректная аутентификация и управление сессией
    •A3 Межсайтовый скриптинг
    •A4 Нарушение контроля доступа
    •A5 Небезопасная конфигурация
    •A6 Утечка чувствительных данных
    •A7 Недостаточная защита от атак
    •A8 Подделка межсайтовых запросов
    •A9 Использование компонентов с известными уязвимостями
    •A10 Недостаточное журналирование и мониторинг

    Потому да, решение было принято однозначно и быстро. Тем более, что как отметил пентестер, подобные изыскания увеличивают безопасность веба в целом:
    Это моё хобби, если каждый разработчик, как Вы, вели бы диалог с баг-хантерами, Интернет был бы безопасен на 80%.

    Потому в целом мы заплатили довольно немного, особенно, если разделить сумму на то количество месяцев, которое сотрудник, отвечающий за тестирование на проникновение, не содержался в штате. Спасибо огромное пентестеру за найденный баг и то что он уделил нам время, мы правда ему очень благодарны. Если кому требуются его услуги — обращайтесь, предоставим с его разрешения контакты.

    Но в этот раз нас убила не уязвимость. Это были мы и особенность работы продукта WHMCS. На каждой ноде у нас установлен удобный продукт управления виртуальными контейнерами — VM Manager, доступ к которому есть у WHMCS для создания, приостановки, и удаления, а также у клиентов — для управления созданным виртуальным контейнером.

    image

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

    Два месяц назад мы решили полностью отказаться от облачного продукта дата-центра, так как начали предоставлять собственное решение с VM Manager, которое позволяет ставить систему в один клик или даже со своего образа:

    image

    И даже предложили его на накопителях NVMe PCIe SSD, которые на порядок быстрее обычных SSD на чтение и до 3-х раз на запись, решение, как и облачное, подлежит апгрейду, серверы стоят от $15 и включают удобную панель управления VM Manager и ISP Manager 5 по запросу бесплатно, поддерживают апгрейд с минимальным шагом 5GB DDR4 RAM, 60GB NVMe PCIe SSD и 3 ядра E5-2650 v4до большего тарифного плана в Амстердаме, Манассасе и Лондоне:

    VPS (KVM) — E5-2650 v4 (3 Cores) / 5GB DDR4 / 60GB NVMe SSD / 1Gbps 5TB — $15 / month
    VPS (KVM) — E5-2650 v4 (6 Cores) / 10GB DDR4 / 120GB NVMe SSD / 1Gbps 10TB — $30 / month
    VPS (KVM) — E5-2650 v4 (9 Cores) / 15GB DDR4 / 180GB NVMe SSD / 1Gbps 15TB — $45 / month

    VPS (KVM) — E5-2650 v4 (24 Cores) / 40GB DDR4 / 480GB NVMe SSD / 1Gbps 40TB — $120 / month

    VPS (KVM) — E5-2650 v4 (24 Cores) / 65GB DDR4 / 780GB NVMe SSD / 1Gbps 65TB — $195 / month
    VPS (KVM) — E5-2650 v4 (24 Cores) / 70GB DDR4 / 840GB NVMe SSD / 1Gbps 70TB — $210 / month
    VPS (KVM) — E5-2650 v4 (24 Cores) / 75GB DDR4 / 900GB NVMe SSD / 1Gbps 75TB — $225 / month

    Потому какой-либо смысл арендовать огромную часть облака дата-центра и предлагать клиентам старые процессоры Е3-1230, хоть и от $3,99 в месяц для нас иссяк. Мы верим в то, что клиенты должны получать максимальное качество и максимум производительности, за минимальную цену, да, мы не можем предложить продукт за $3,99 и возможно не покрываем потребности некоторых разработчиков, которым достаточно минимальных ресурсов и любой производительности, но нода стоит свыше 7000 евро и мы не можем себе позволить, во всяком случае пока, размещать на ней более 15 клиентов, так как готовы гарантировать качество. И качество подразумевает не только стабильность, но и максимальное соотношение производительность / цена, то cost-эффективность.

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

    А сегодня, спустя 2 месяца, мы решили «Отменить» (не удалить, такая кнопка там также есть, но мы стараемся никогда ничего не удалять, чтоб всегда была история) 1000+ ожидающих заказов, которым всё ещё не был присвоен статус в биллинге WHMCS. Догадались? Да, это оно. У меня спросили — можно отменять? Я подтвердил «удаляй».

    Порой, несмотря на большое количество ресурсов, так как выборка данных большая и какой-то процесс не укладывается в отведённый лимит времени, WHMCS выдаёт 504 ошибку, при этом всё выполняется и биллинг продолжает работать, но тут мы получили недоступность. Биллинг и сайт перестали быть доступными. Мы не сразу поняли причину. Но потом осознали. Заказ на наши 2 VPS не был акцептирован (да, мы не приняли свой же заказ!) и как следствие «Отменён» системой, что привело к запуску модуля и удалению сразу двух контейнеров, якобы не созданных, но всё же созданных виртуалок, при помощи нашей любимой VM Manager. Зайдя на одну из нод, как и предполагалось, наши администраторы увидели картину «Прощай»:



    Что это — недочёт разработчиков WHMCS, который приводит к удалению неакцептированных заказов, и реально созданных с их ID VPS, при их отмене, или наша тупость (отдела продаж) — уже не важно. Результат был один — «Прощай сайт с биллингом». Панель их просто затёрла. А у администраторов к нам (продажам), был только один вопрос:

    Нахера создавать услугу со своим главным сайтом и биллингом.
    А потом ещё и убить ее к чертям.

    И хотя у нас были бекапы, также в двух географически распределённых регионах, мне стало не по себе. Так как я не был уверен за свежесть резервных копий, не уверен был в том, что наши администраторы сделали всё верно, как было прописано изначально в тех. задании, что база резервировалась реально каждый час или даже чаще, а данные обновлялись и хранилось несколько предыдущих версий файлов. Что бэкапы по какой-то программной ошибке не перестали делаться вообще (ведь я лично это не котролировал, почему я должен быть уверен, что о наших данных будут беспокоится наши администраторы, если я на этот контроль забил?). Куча негативных мыслей… Не дай Вселенная Вам пережить такое!

    Я уже собрался с мыслями, что как минимум за 1 час, а то и хуже, транзакций не будет, и придётся восстанавливать платежи клиентов вручную, сопоставлять данные по предидущим транзакциям и писать владельцам аккаунтов на счёт того, что мы повторно создали счёт и оплатили его, показать себя с ненаилучшей стороны, разослать уведомление, что мы дураки и допустили такой программный сбой… А если нет свежего бэкапа — так это вообще труба, пришлось бы очень долго и муторно восстанавливать всё…

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

    Благо, всё оказалось не столь плохо, и даже у тех. специалиста, которому пришлось решать проблему и который в начале огласил:

    Вечер удался, всем спасибо.
    Пошел поднимать.

    Всё же вечер удался. Так как изначально решение предусматривало использование lvm и новый виртуальный контейнер ещё не успел быть создан — получилось восстановить актуальные данные, хотя и с танцем с бубном:

    Всё через lvm утилиту, с помощью её команд восстановили виртуальных группу томов, потом виртуальный, далее активировали раздел, смаунтили на левую папку, создали сервер и туда засинкали данные. Можно было и другими способами, но этот вариант в нашем случае был самым быстрым + специфика настроек виртуальных серверов, что каждому свой рейд.

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

    Необходимо всегда иметь внешнее независимое от Вашей системы хранилище, с доступом, желательно только по какому-то коду, которое также резервировано, чтоб уж точно гарантировать то, что данные не будут утеряны. В данный момент, несмотря на наличие бэкапов в нашей инфраструктуре в двух регионах, я в серьез рассматриваю возможность использования что-то типа Amazon Glacier, хотя последний очень дорог. По словам администраторов там всё хорошо только в маркетинговом плане, но когда начинаешь пользоваться — сталкиваешься с тем, что решение стоит довольно дорого, так как приходится платить за каждый запрос и каждый файл, который очень интересно считается их приложением aws-cli, особенно, если данные нужно восстанавливать. Недавно один клиент из Британии просил настроить резервирование там, по итогам через несколько месяцев пользования отказался — оказалось очень дорого. Но всё же, нам нужно определится с тем, что дороже. И если бюджет на резервирование там не превысит суммы возможного ущерба в результате потери части данных — мы обязательно воспользуемся. Если же нет — начнём искать другое, лучшее по цене, но всё же независимое от нас решение. Чтоб обеспечить дополнительную надёжность и уверенность в том, что данные не будут утеряны.

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

    P.S. События произошли сегодня, в пятницу (публикуется в пятницу, по EST времени). Извините за много букв, решил отписать, пока свежо в воспоминаниях. Надеюсь, мой опыт будет кому-то полезен и убережет от подобной беды. И в пятницу Вы будете наслаждаться вечером перед выходными, а не писать статью об ошибках, как это делал я. Хотя, что не есть — то к лучшему, всё могло быть гораздо хуже. Не стесняйтесь делиться своими факапами в комментариях. Всем приятных наступающих и уже наступивших выходных!

    На правах рекламы.

    VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps в Нидерландах до декабря бесплатно при оплате на срок от полугода, заказать можно тут, скидка 30% на первую оплату VPS в Нидерландах, США, Англии тут.

    Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

    ua-hosting.company

    635,83

    Хостинг-провайдер: серверы в NL / US до 100 Гбит/с

    Поделиться публикацией
    Комментарии 19
      +31
      Только прочитав всю статью я понял, что под «поговорим об избыточности» подразумевалось что всю статью можно ужать
      до одного предложения
      Я работаю в отделе продаж в небольшой украинской хостинг-компании, мечтающей стать крупной за счет средств, в частности, Дмитрия Суханова, но нам не везет, потому что мы купили лицензию на софт для управления хостингом, но нажали кнопку «удалить всё».


      А потом два блока рекламы еще. Спасибо за пост. Отличный получился.
        –1
        Какое-то длинное предложение. Если тезисно и без рекламы, то «Необходимо всегда иметь внешнее независимое от Вашей системы хранилище»
          +2
          Но ведь тогда нельзя будет добавить «нативную» рекламу в статью!
          А компания, на мой взгляд, поступила достойно, честно рассказав о своём промахе.
          +3

          Я вообще не понял при чем тут геокластер, если удаляли из биллинга, который удаляет услугу, а не отдельный сервак.

            +4
            Мде убили биллинг биллингом… Неужели нельзя было сделать специальную группу вместо «протектед», например «перманент», и не выставлять инвойсы (т.е. именно не отправлять, а не рассчитывать) для такой группы.
              +1
              ну или на край прямо в VM Manager завести себе аккаунт и под ним поднять ВМ(ы)- которые с биллингом никак не связаны… и удалять их можно будет только из самого VM Manager
                +5
                Задним умом все крепки. Всё можно было сделать, но не всё можно заблаговременно предусмотреть.
                +6
                предоставляем клиентам решения различной степени сложности, иногда такой, что даже сами затрудняемся разобраться в том, что сотворили.

                Неплохая реклама.

                  +7
                  Такое ощущение. что все комментирующие не допускали факапов… Молодцы, что рассказали, открытость при совершении ошибок дорогого стоит.
                    +1

                    На самом деле от человеческого фактора уберечься (за вменяемые деньги) невозможно. У вас, по описанию, всё было сделано достаточно адекватно, кроме отсутствия регулярной проверки бэкапов. Бэкапы обязательно нужно не реже раза в месяц (для компании ваших размеров — скорее в пару недель) восстанавливать и проверять работоспособность и данные восстановленной системы. Желательно — автоматизированно (прогнать на нём штатные приёмочные тесты), с отправкой отчёта в общий чатик со статистикой "бэкап 2018-09-22 проверен, X юзеров, Y серверов" — это позволит глазками заметить фигню если числа X/Y вдруг стали странно маленькими (что приёмочные тесты вряд ли могут проконтролировать).

                      0

                      Похоже на то, как летом админы AWS вырубили несколько S3 серверов на пробу и обрушили немалую часть своей инфраструктуры.

                        +12
                        «Мы получаем много заявок, но не можем в них разобраться, поэтому время от времени удаляем по тысяче заявок. Кому что-то было правда нужно — перезакажет»

                        Вот это огонь.
                          +1

                          Это самое эпичное.

                            +5

                            Вспомнился анекдот. Опытный HR учит молодого, как обрабатывать большое количество резюме: берёт, и не глядя, выкидывает 2/3 стопки резюме в мусор. Молодой воклицает:
                            — Что вы делаете?!
                            — От этих кандидатов просто отвернулась удача… Ну, а зачем нам нанимать неудачников.

                            0
                            По сути это было самоубийство биллинга.
                            Когда случаются подобные вещи в голове всегда что-то переключается и думать начинаешь немного по другому.
                              0
                              У меня однажды вышло наоборот: в список демона, перезапускающего упавшие процессы, добавили его самого же, причём так, что процессы множились. Получившееся чудо не мог убить даже killall -9: пока он проходит середину списка, конец списка успевает восстановить начало. Пришлось дважды ребутать сервер в праймтайм.
                              +1
                              Красивая реклама, даже захотелось что нибудь прикупить у них. Но…
                                +5
                                Вашу заявку удалят…

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

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