• Как запустить ClickHouse своими силами и выиграть джекпот
    0
    А как реализовывали, у них есть какое-то формальное описание грамматики?
  • Хайлоад в облаке на живом примере
    0
    Мониторинг собственный и опирается в основном на сырые метрики процессов/системных величин/интерфейсов. Хранится статистика в Oracle NoSQL — распределенной KV базе данных.
  • Cloudmouse закрывается
    +1
    Хотелось бы дать комментарий и с нашей стороны, от имени Flops.ru.

    К сожалению, рекомендательная ссылка на нас в единственном экземпляре вызвала некоторые вопросы об аффилированности между нами и Cloudmouse у ряда клиентов и создала для нас некоторые репутационные издержки.

    В ответ на эти вопросы хотим отметить: к Cloudmouse мы отношения не имеем, закрываться не планируем, потерь клиентских данных с момента запуска в феврале 2013 года не было и предпосылок для этого нет.

    Как бы странно это ни звучало, об этом посте и рекомендации нас в качестве альтернативы мы узнали постфактум от вновь прибывших клиентов, что в итоге вызвало некоторые неудобства (число желающих получить триал превзошло объем зарезервированных под это ресурсов). Мы эту ситуацию сравнительно быстро на наш взгляд отыграли, к вечеру вчерашнего дня все желающие триальные серверы получили:

    image

    Мы сожалеем о событиях, связанных с Cloudmouse и приложим максимум усилий, чтобы обеспечить качественный сервис тем клиентам, которые решили воспользоваться рекомендацией.
  • Что не договаривают сервисы по защите от DDoS или почему защита не работает
    0
    Надо также помнить про отпечаток сервера, начиная от списка открытых или закрытых портов и версий сервисов и заканчивая такой экзотикой, как публичный ключ на 22 порту (если вдруг он катается вместе со всем остальным). Также иногда встречается вариант, когда атака бьет по всем адресам в истории по очереди, стараясь найти нужный, поэтому шаги с переездом на предыдущие адреса лучше не предпринимать.
  • Как Elasticsearch может помочь в поиске подозрительной активности на сайте
    +1
    Получился довольно ироничный заголовок. Дело в том, что если взять ElasticSearch и проанализировать подозрительную активность на больших объемах, то почти наверняка попытки взлома этого самого ElasticSearch будут в лидерах :)
  • Cloudmouse удалил все виртуальные сервера
    0
    Звучит похоже на то что у них одновременно полностью рассыпался консенсус из mon и данные самих мониторов были дополнительно полностью утеряны, я правильно понимаю ситуацию?

    Ceph надежен для продакшена (хотя и капризен), дело практически наверняка в кривых руках, особенно принимая во внимание факт, что не было бэкапов на внешнем хранилище.
  • Cloudmouse удалил все виртуальные сервера
    +5
    Это и есть OpenStack :)
  • Ceph: Cloud Storage без компромиссов
    0
    В первом вопросе у вас заключается сам ответ — да, безусловно, состояние и конфигурация виртуалок остаются. У нас нет противопоставления опенстековскому boot from volume — все машины всегда работают только с rbd. В этом случае нода приравнивается к сгоревшей и машины также перезапускаются.
  • Введение в Distributed Switch Architecture: технология управления сетью как единым устройством
    0
    На ваш взгляд, на какой сегмент этот стандарт рассчитан? Через некоторое время весь крупный свичинг, скорее всего, приведется к OF-DPA, а у DSA гибкость в разы меньше, поэтому нишу для него сложновато представить.
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Безусловно, отделить можно, просто он тут на ровном месте и большой. Допустим, однократная процедура бекапа 200гбайт-образа выльется, при скорости блочной миграции ну 200мбайт/с, в 40+ минут только на переезды плюс ну полчаса минимум (в реальности скорее 2-3 часа) на отслаивание образа, даже если не брать его сжатие. Процедура восстановления займет, с учетом спиноффа прямо на бекап-сервере и последующего переезда, минут 20. Теперь ухудшаем ситуацию до двух-трех таких операций в параллель и получаем насыщение на уровне очередности операций, при этом принимая допущение, что бекап-сервер обладает как минимум десятигигабитным интерфейсом, у него хватает на все задачи процессора и нет вероятности появления более срочной и приоритетной операции.

    Принимая во внимание тот факт, что вы отстраиваете решение на локальном хранилище, непонятно, зачем использовать блочную миграцию для бекапов вместо операции drive_backup, это втрое уменьшит объем сетевого трафика. Ну из из топорной калькуляции выше видно, что проблемы наступают очень рано, примерно на уровне пары-тройки компьют в расчете на один бекапсервер (бекап раз в 3..7 дней, компьюты содержат ну пусть 2Тб данных каждая).
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Для примера «не зацепить» можно взять работающий докер. Проблема оверхеда в том, что он создается в рамках одной ноды и влияет на нее же. LVM миррор и DRBD в современном мире действительно, никто не использует :)
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    > а как же тогда работает живая блочная миграция?

    имелся в виду вариант без нее, п.2

    Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого? Да, cow плох, когда он не обеспечивается большой хранилкой, переваривающей операции со снимками без потерь, цеф там будет или нетапп — уже вторично, поэтому его использование в большом продакшене отпадает. Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды.
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Да, безусловно, с довольно давних времен консистентный дамп всего в qemu стал делаться быстро для cow образов, но из использования такого блокбекенда вытекает масса явных и неявных проблем при масштабировании одной виртуалки или при масштабировании их группы. Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно, но там доделки на два рубля. Все же мы обсуждаем очень нишевое решение, процент пользователей, которым действительно необходим полный стейт, а фриза фс внутри недостаточно, очень невелик и у них как правило есть возможность раскошелиться на коробочный вариант.
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Хорошо, заменяем фриз на отслаивание памяти (не прямым дампом, а мигратоподобным вариантом или его аналогом, как выше) и снимком на хранилище из п.2, получаем тот же простой в районе долей секунды и ту же «абсолютную консистентность». Месседж с моей стороны таков, что попытка сделать указанные вещи на обычных локальных образах, raw или cow, приведет к очень высокому оверхеду из-за необходимости прокачивать большой объем данных в первом случае и потенциальной необходимости отслаивать снимки и также прокачивать много байтов во втором, без отслоения надо либо их ротировать, либо все затормозит. Впрочем, такой подход вполне себе имеет право на жизнь, если время доступности бекапа с момента его создания может сильно варьироваться и не регламентировано жестко (доступность = выкачанность на другую физическую сущность).

    В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого.
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Уточню, акцент на ресурсоемкости такого флоу в целом.
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    А какие плюсы этот подход дает? Если продолжать держать информацию о снимках в образе, чтобы получать дифференциальные детачнутые копии, то это будет растить размер блок-бекенда, который еще по замыслу катается между машинами, если снимать каждый раз полный дамп — проще воспользоваться drive-backup или чем-то схожим по смыслу и ничего никуда не мигрировать (похоже вариант 3, если имелось в виду то же). В любом случае, двойная блочная миграция в процессе не выглядит продакшеном :)
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Мигрирует блочной миграцией? Вообще описанный вариант про корку из коробки недоступен, хотя его можно сделать минимальными силами, и опять же пока дисковый снимок отклеивается (если в этом есть необходимость), все может тормозить. И зачем в любом случае мигрировать машину для снятия бекапа?
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Нюанс в том, что все вариации на эту тему очень небыстрые, для промышленного флоу их использовать сложновато. Плюс корка сейчас на лету без простоя не снимается, что ведет к еще большим потерям :).
  • Ceph: Cloud Storage без компромиссов
    0
    Чем больше число PG, тем более гладким получится псевдослучайное распределение данных. С другой стороны, при числе PG более 50..70к в одном пуле начинаются проблемы с производительностью кластера.
  • Ceph: Cloud Storage без компромиссов
    0
    В случае обычного коммутатора вам с очень большой вероятностью хватит линуксового balance-xxx. У цефа нет точек, являющихся средоточием пропускной способности, так что половинка от максимальной скорости на пару 5-tuple будет очень хорошо работать, за исключением граничных случаев (один клиент, потребляющий всю пропускную способность кластера).
  • Ceph: Cloud Storage без компромиссов
    0
    Multipath не нужен в силу архитектуры продукта, можно использовать обычный бондинг для большей отказоустойчивости отдельной ноды хранилища.
  • Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM
    0
    Описанный подход прекрасно работает, если совмещать его с дисковым бекендом, позволяющим делать атомарные снимки — у нас в Flops.ru бекапы создаются именно таким образом, при этом использование открытых компонент позволяет получить желаемое бесплатно. Единственный недостаток такого подхода — файловые системы, которые отказываются фризиться по каким-то причинам, в БД-ориентированном шаблоне это может обходиться выносом datastore БД на отдельную (эксклюзивную) точку монтирования.
  • О Nutanix, Web-Scale, конвергентных платформах и смене парадигм построения IT инфраструктур
    0
    Еще один момент — не припоминается ни один LFN-оптимизированный алгоритм, который бы подошел к этой задаче на сто процентов. Это не к вопросу о вытягивании нюансов, просто интересно, существующий используется или свой.
  • О Nutanix, Web-Scale, конвергентных платформах и смене парадигм построения IT инфраструктур
    0
    Вы используете TCP транспорт для этих целей или что-то иное? RTT в 5мс будет очень сильно ограничивать возможности синхронных операций для профиля нагрузки с резкими всплесками записи, так что эта затея по большей части малореальна на приличном ио из-за фундаментальных лимитаций.
  • О Nutanix, Web-Scale, конвергентных платформах и смене парадигм построения IT инфраструктур
    +1
    У хадупа другие задачи и возможности, впрочем, авторы статьи могут сами перечислить различия. Экосистема Nutanix довольно близка к нам (Flops), где-то он существенно нас превосходит (в плане интеграции протоколов хранилищ и локализации данных), где-то наш стек умеет то, что в nutanix не реализовано вообще (SDN, к примеру).
  • SSD ULLtraDIMM от SanDisk под слоты памяти DDR3
    0
    Судя по всему, в платформы, которые не понимают что такое ULLtraDIMM их не вставишь? Или работа с ними будет на программном уровне?

    В доках писали что нужна поддержка UEFI.
  • Хайлоад в облаке на живом примере
    0
  • Хайлоад в облаке на живом примере
    0
    Подсчитайте на досуге вероятность проявление ошибки в non-ECC памяти, на какие приложения это может повлиять, а также про методы контроля данных как в системе, так и в приложениях.

    ECC не только исправляет ошибки, но и позволяет обнаруживать бракованные/склонные к ошибкам планки. Имея не-ECC память, вы фактически не имеете средств диагностики таких ошибок. При этом симпоматика у них такова, что причина (битая планка памяти) будет ясна далеко не на первом фейле. Ну а когда поймете, что виновата память — придется гонять мемори-тесты, чтобы понять какая именно планка фейлит.

    Зачем горячее резервирование электропитания на сервере? У вас проблемы с электропитанием? у вас часто выходят из строя БП?

    Во-первых да, БП горят, это нормально. Во-вторых, что не менее важно, качественные ДЦ предоставляют две независимые линии питания, и даже если по одному лучу питание пропадает, оборудование продолжает работать.

    В принципе, этих аргументов достаточно, чтобы понять, что консьюмерское железо не стоит использовать там, где от аптайма зависит финансовый результат компании.
  • Хайлоад в облаке на живом примере
    0
    У них т.н. shared private network, которая не изолирована между клиентами. По большому счету единственное, чем она может быть полезна — это возможностью бесплатно гонять трафик между машинами. Можно конечно вооружиться iptables и самоизолироваться, но полноценной локальной сети получить все равно не удастся.
  • Хайлоад в облаке на живом примере
    0
    Не понял, где тут хайлоад

    Как мы отметили в начале статьи, все относительно и данный проект не претендует на рекорды. Тем не менее, решаемая клиентом проблема ненамного слабее C10K, да и характерные для хайлоада проблемы уже встречаются.

    и где тут облако в понимании облака. Просто поменялось место расположения виртуалок.

    Рестарт машины при вылете хоста (High Availability), возможность за секунды создавать/клонировать/удалять виртуальные серверы, возможность подстроить конфиг без рестарта сервера, приватная локальная сеть — это все про облака.
  • Хайлоад в облаке на живом примере
    0
    Спасибо, приятно слышать :)
  • Хайлоад в облаке на живом примере
    0
    Вообще сложно представить задачу, когда нужно _столько_ памяти.

    72Гб памяти — это суммарная потребность в памяти вообще всех приложений (включая несколько Windows-машин). Не беремся судить, насколько это потребление оптимизируемо, т.к. это лучше известно самому клиенту. Но предполагаем, что раз клиент этим не занимается — наверное стоимость оптимизаций будет для него выше, чем переплата.

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

    Описанная схема работает только для УСН/ИП 6%.
    Для всех остальных есть два варианта. Либо ваша компания заводит счет в евро и платит зарубежному контрагенту безналом (что сопровождается валютным контролем, высокими комиссиями за перевод, абоненткой за валютный счет итд), либо вы не имеете права списать данные средства в расходы.
  • Хайлоад в облаке на живом примере
    +1
    Опять голословные утверждения. Подсчитайте на досуге вероятность проявление ошибки в non-ECC памяти, на какие приложения это может повлиять, а также про методы контроля данных как в системе, так и в приложениях.

    Голословные утверждения — это ваши мифы о том, что консьюмерское железо равноценно серверному по надежности. Разница ECC и не-ECC это один из многих факторов отличия. У консьюмерского нет горячего резервирования БП, никто не тестировал его на возможность бесперебойной круглосуточной работы, неизвестно, что там будет с охлаждением при многочасовой «прожарке» CPU, отсутствует IPMI… Можно найти много отзывов на предмет hetzner'овского low-end железа, в том числе от хостеров, которые продавали на таком оборудовании VDS и в итоге отказывались от этой практики именно по причине непредсказуемости.

    По грубым прикидкам аренда этого сервиса (нагрузка чуть выше обычного сервера хостинга ) в Европе будет не дороже 15k рублей. Эту сумму можно оплатить или как физ. лицо или через 10-к посредников (+20%-40%) как юр лицо.

    Дороже. См. выше.
  • Хайлоад в облаке на живом примере
    0
    Если смотреть на требования к конфигу в данной конкретной задаче (72+ GB RAM, 2TB быстрого диска), то речь может идти либо о PX120, либо PX120-SSD c кастомной конфигурацией дисков. Итоговый прайс за 2 сервера — в районе 25 тысяч рублей, плюс что-то нужно будет делать с каналом/трафиком наверное. Так что не могу сказать о существенной разнице.

    По поводу юриков — у них есть российское юр. лицо то бишь?
  • Хайлоад в облаке на живом примере
    +1
    Будьте добры, более подробно привести аргументы.

    В случае, если у вас есть 2 dedicated сервера (каждый со своим сторейджем) вы конечно можете попробовать организовать горячий резерв, настроив репликацию БД и подняв фейловер для каждого сервиса. Но это повлечет расходы на работу админа, необходимость постоянного контроля и периодических проверок работоспособности. И все равно не будет гарантий, что в час X все отработает так, как нужно.

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

    Также непонятен, в чем экономический эффект, если арендованные сервера и VPS в Хетзнер, ОВХ и Онлайн.net довольно доступные по цене.

    Что касается Hetzner. Если речь об их бюджетном железе, то оно консьюмерское (Core i7, non-ECC RAM) и использовать его для подобных задач себе дороже. Если выбирать и конфигурировать Dell'ы, то в итоге прайс будет сопоставим. При этом вы получите серверы расположенные в Европе (то бишь пинг будет десятки миллисекунд) и у вас не будет возможности платить за услуги с юридического лица (что актуально, когда ежемесячный счет за хостинг — несколько десятков тысяч рублей). Вывод — вариант так себе.
  • Хостинг: продолжайте делать то же самое, вас уже съели
    +1
    хостинг — не интернет-проект :)
  • Хостинг: продолжайте делать то же самое, вас уже съели
    0
    В этом случае можно сравнить отклик — у нас 99 процентов такого теста уложатся в 2-5 мс, что вряд ли возможно на счетверенном сасе. 400 IOPS записи для минимального инстанса — вполне себе хороший предел, никто даже близко к нему не подбирается в реальных задачах. У нас нет задачи продемонстрировать цифры с многими нулями, задача скорее сделать работу приложений очень быстрой. Выбранные параметры лимитов вкупе с низким откликом эту задачу решают настолько же успешно, насколько и сырой массив из SSD с соответствующим прайсом.
  • Хостинг: продолжайте делать то же самое, вас уже съели
    0
    1. В любом случае они не могут отдавать такую полосу всем клиентам, значит, это очень большой оверкоммит, только и всего. Детали архитектуры, в принципе, ищутся в гугле, я не хочу выступать адвокатом дьявола и «мочить» то, о чем не знаю деталей, но выводы после просмотра разрозненных подсказок можно определенные сделать — и по лимитам, и по будущим потенциальным сложностям. Даже если ничего не искать, голос разума подсказывает, что те огромные цифры, которые выдаются на бенчмарка диджиталоушена, точно не могут равномерно раскладываться по всем клиентам.
    2. Это своего рода этикет — к нам, например, открыто пришел работник конкурирующего продукта, взял самый крупный инстанс на тестовом периоде и нагрузил его по самое не хочу по всем характеристикам, заявив потом, что у нас все плохо :). Cрезать скорость в середине тестирования, наверное, самый большой удар по репутации, кроме собственно падений, потому я понимаю причины, почему у вас итоги оставались постоянными.
  • Хостинг: продолжайте делать то же самое, вас уже съели
    +1
    Вы поймали лимит, то есть ограничение по иопсам. Цифры с диджиталоушена говорят только о том, что у них ресурсы лимитируются с очень большим оверкоммитом или не лимитируются вообще, поэтому намерянное не будет гарантировано. Минус в том, что на эту удочку клюют многие и несут свои сайты туда, где цифры в тестах выше, невзирая на логику — всем такой объем ресурсов одновременно не отдать, а пиковые значения могут меняться на порядок в зависимости от загрузки дискового ресурса соседями. В данном случае 10к IOPS — значительная часть ресурса приличного хранилища с многоуровневым кешированием. Мы выбрали другой путь — цифры удивляют меньше, зато они не являются пиковыми, то есть не будут меняться со временем, хоть и в каком-то смысле это идет в ущерб маркетингу.
  • SYN-флудим со спуффингом на 14 mpps или нагрузочная вилка V 2.0
    +3
    В чем повод для беспокойства? Никто из атакующих не будет запускать такую конструкцию, она обрушит ему же канал на стыке с ближайшим сетевым устройством.