О Nutanix, Web-Scale, конвергентных платформах и смене парадигм построения IT инфраструктур

    Возможно, вы уже слышали достаточно новый для рынка не_онлайн проектов термин — Web-Scale IT, который по мнению Gartner в 2017 году займет не менее 50% рынка корпоративного IT.

    В этом году — это один из основных модных терминов.

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

    Буквально каждый вендор рассказывает про BigData, конвергентные решения, перспективы и прочее.

    Мы в свою очередь смеем надеяться, что у нас с этим реально все весьма неплохо, но тут всегда виднее со стороны и ваше мнение может не совпадать с нашим.

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

    image



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

    Компания основана в Кремниевой долине в 2009 году ключевыми инженерами Google (разработчиками Google Filesystem), Facebook, Amazon и других глобальных проектов, а с 2012 года расширяется в Европу и подключает инженеров из ключевых Европейских команд (например, Badoo).
    Названы самым быстрорастущим технологическим стартапом последних 10 лет, уже вошли в рейтинг Gartner как визионеры (технологические лидеры) индустрии конвергентных решений.
    По мнению Forbes, являемся лучшим в мире «облачным» стартапом для работы
    Да, у нас есть инженеры в России, и будет значительно больше. Растем.

    Собственно, в нашем ДНК — крупнейшие в мире интернет проекты, с основной идеей — работать всегда и для любого масштаба / объема данных.
    Базируемся на open-source компонентах, доведенных до ума с помощью большого напильника — Cassandra для хранения метаданных файловой системы (с маневром обхода CAP теоремы по принципу «умный в гору не пойдет» и доработкой в строну CA), Apache Zookeper для хранения конфигурации кластера, Centos Linux и файловая система EXT4.
    Активное использование BigData технологий внутри (по настоящему, а не маркетинг).

    В общем, умеем.

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

    К статье приложены иллюстрации (того как работает Nutanix), и детальное техническое описание будет в последующих статьях (вы же не хотите читать статью всю ночь?)

    Итак, поехали! (с) Гагарин.

    image

    ….

    Web-Scale



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

    Базовые принципы:

    • Гипер-конвергентность
    • Чисто программная реализация (Software Defined)
    • Распределенные и полностью самодостаточные системы
    • Линейное расширение с очень точной гранулярностью


    Дополнительно:

    • Мощная автоматизация и аналитика с помощью API
    • Самоизлечение после отказов оборудования и датацентров (катастрофоустойчивость).

    Раскроем смысл?



    Гипер-конвергентность


    image

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

    В случае с Nutanix, мы говорим о том, что наша платформа объединяет в себе компьютинг и хранение данных. Другие компании могут например говорить (и это тоже будет гипер-конвергентным) о том, что объединяют CХД (систему хранения данных) с сетью, или множество других вариантов.

    Нативная интеграция двух или более компонент в случае Web-scale дает линейное (горизонтальное) масштабирование без каких-либо лимитов.

    Как следствие, мы получаем существенные преимущества:
    • Масштабирование по одной единице решения (как кубики Лего)
    • Локализация ввода-вывода (крайне важно для массивного ускорения операций I/O)
    • Устранение традиционных СХД как рудиментарных, с интеграцией в единое решение (нет СХД — нет проблем с ней связанных)
    • Поддержка всех основных технологий виртуализации на рынке, включая open-source (ESXi, HyperV, KVM).


    Чисто программная реализация


    image

    Перенос всей логики из (крайне сложного) пропиетарного оборудования (спец-процессоры, ASIC / FPGA) в 100% программную реализацию.

    Как пример, в Nutanix мы выполняем любые (и зачастую уникальные — такие как дедупликация RAM кэша, распределенная map/reduce отложенная дедупликация данных на кластере и т.д.) операции программно.
    Многие спросят — это же должно дико “тормозить”? Никоим образом.

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

    Компрессия данных (отложенная и “на лету”)?
    Легко, свободный алгоритм snappy, используемый Google.


    Резервирование данных?

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

    Если очень коротко, то проблема RAID даже не только скорость его работы, но время восстановления после отказов аппаратных узлов (дисков, полок, контроллеров). Например, в cлучае с Nutanix, после отказа жесткого диска на 4TB, восстановление целостности системы (количества реплик данных) для 32 узлов в кластере под тяжелой нагрузкой, занимает всего 28 минут.

    Сколько времени будет перестраиваться большой массив (скажем на сотни терабайт) и RAID 6 — думаем, вы сами в курсе (многие часы, иногда сутки).

    Учитывая, что уже сейчас готовы гелиевые диски на 10TB, для традиционных СХД наступают совсем тяжелые времена.

    image

    На самом же деле, «все гениальное — просто». Вместо использования сложных и медленных RAID систем, данные должны разбиваться на блоки (так называемые extent groups в нашем случае) и просто “размазываться” по кластеру с нужным количеством копий, причем в peer to peer режиме (в русскоговорящем пространстве пример торрентов сразу всем понятен).

    Кстати, отсюда вытекает новый для многих (но не для рынка) термин — RAIN (Redundant/Reliable Array of Inexpensive/Independent Nodes) — резервируемый / надежный массив из недорогих / независимых нодов.

    Ярким представителем данной архитектуры как раз и является Nutanix.

    image


    Звучит сложно? Сокращаем: выносим всю логику работы из железа в чисто программную реализацию на стандартном X86-64 оборудовании.
    Ровно так-же как делает Google / Facebook / Amazon и прочие.

    Какие преимущества?

    • Быстрый (очень быстрый) цикл разработки и апдейтов
    • Отвязка от зависимостей к пропиетарному оборудованию
    • Использование стандартного (“ширпотреб”) оборудования для решения задач любых масштабов.


    Распределенные и полностью самодостаточные системы


    image

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

    Перефразируя — чисто распределенная система.

    image

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

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

    Мы говорим о «самоизлечивающихся» системах, причем излечение должно происходить максимально быстро.

    image

    Если логика управления требует координации (так называемые «master» узлы), то выбор оных должен быть полностью автоматическим и любой участник кластера может стать таким мастером.

    Что это все означает в реалиях?

    • Распределение ролей и ответственностей внутри системы (кластера)
    • Использование BigData принципов (такие как MapReduce) для распределения задач
    • Процесс «публичных выборов» для обозначения текущего мастера


    Линейное расширение с очень точной гранулярностью



    Последовательное и линейное (горизонтальное) расширение обозначает возможность стартовать с определенного количества ресурсов (в нашем случае — 3 узла / нода / сервера) и масштабироваться линейно для получения линейного-же прироста производительности. Все пункты, которые мы обсуждали выше, являются критичными для получения такой возможности.

    Как пример, обычно вы имеете трех-уровневую архитектуру (сервера, система хранения данных, сеть), каждый элемент которой масштабируется независимо. Если увеличили число серверов — то СХД и сеть при этом остались старые.

    C гипер-конвергентной платформой типа Nutanix, при добавлении каждого нода, вы получите увеличение:

    • Количества гипервизоров / компьютинговых нодов
    • Количества контроллеров СХД (3 нода = 3 контроллера, 300 нодов = 300 контроллеров, и т.д.)
    • Процессорные мощности и емкость СХД
    • Количество нод участвующих в решении задач кластера


    Сложно? Упрощяем:

    • Возможность масштабировать сервера и СХД по одному микро-узлу с соответствующим линейным увеличением производительности, начиная с 3-х и до бесконечности.


    Преимущества:

    • Возможность стартовать с минимального размера
    • Устранение любых «бутылочных горлышек» и точек отказа (да, SLA 100% реален)
    • Постоянная и гарантированная производительность при расширении.




    image

    В следующих статьях мы дадим больше технических подробностей и расскажем, для начала, как работает наша NDFS — распределенная файловая система нового поколения, построенная на ext4 + NoSQL.

    Из дополнительных анонсов — наша система управления KVM, которая работает по тем-же принципам, безлимитно масштабируема и не имеет точек отказа.

    Мы будем выступать на Highload 2014, показывать наши решения «вживую». Приходите.

    Хорошего дня!

    p.s. да-да, мы обязательно расскажем что мы выбрали из CAP и как решали вопрос Сходимости-Доступности-Партиционирования
    p.p.s. (если кто-то дочитал до этого места) для внимательных — конкурс, угадайте как называется наше решение для управления KVM и получите приз (в Москве).
    Nutanix 37,50
    Компания
    Поделиться публикацией
    Комментарии 82
    • +1
      Участвую в конкурсе самых внимательных, надеюсь, что много вариантов можно
      Nutanix, Nutanix Acropolis, Nutanix KVM.
      Последний вариант на уровне кэпа, но, а вдруг?)
      • +1
        Ну, первый же пост — и сразу правильно!

        Поздравляем с выигранным термосом Nutanix. Хорошего чае-кофе-пития в машине или на работе ;)

        Nutanix Acropolis.
        • 0
          Расскажите про дальнейшие наши действия, пожалуйста :)
          • 0
            Наши инженеры свяжутся с вами, или же если будем на Highload — передадим там

            Опишите пожалуйста свой телефон в «личку».

            Термосы хорошие!
      • +5
        К сожалению на мой взгляд без маркетинга обойтись в статье не удалось (да и где сейчас от наго спрячешься :)?). Пока в основном вижу только размахивание чужими флагами (Google / Facebook / Amazon). Да и по описанию плюс/минус то же самое что и у остальных вендоров, начинающих развивать Software Defined решения.
        За сим ждем ждем технических подробностей, что бы понять «в чем уникальность?» :) и «почему всем нужен именно Nutanix?».
        • 0
          Безусловно, целью конкретной статьи не ставилось сделать deep dive.

          Статьи будут, и там уже сделаете выводы.

          Насчет плюс-минус — тут можно вопросом на вопрос :)

          Назовите любое другое software-defined решение на рынке, не имеющее границ по масштабированию (ввиду использования NoSQL)(VSAN / EVO:RAIL — 32/16 нодов, ввиду того что это просто сетевой RAID), отсутствии точек отказа (сервера блокировок и прочее как например GPFS), так-же как выдерживающее множественные отказы оборудования одновременные, и работающее с HyperV / KVM / ESXi (ceph уже не вариант).

          Реально, возможно что-то упустили и про что-то не знаем.
          • +1
            По общим принципам похожи на ceph :) ну во всяком случае такое ощущение складывается. И да — много флагов, которые пока не ваши)) сделайте инженерное сравнение nutanix, CEPH, openvstorage.
            • 0
              Прочитайте чуть ниже я отписал.

              Не стоит путать (замечательный) проект (Ceph) и готовый продукт (Nutanix).

              По поводу что умеет Ceph — сами вычеркните из списка «лишнее».
            • 0
              Ну про выдерживание множественных отказов — это мы будем делать выводы после «deep dive» :).

              Ну что за практика ответов вопросом на вопрос? Давайте тогда и я попробую так же :).

              Решение работает с HyperV / KVM / ESXi одновременно в том числе?
              Или как насчет работы не только с гипервизорами, в средах где пока еще не все можно (или не все успели) перенести в виртуализацию?
              Как насчет сервисов, для которых производительности одной стандартной ноды Nutanix не достаточно?
              Как насчет работы с «разномастными» нодами по составу железа (и вообще с «китайским» самосбором)?

              Остальные вопросы оставлю для технических статей ;), вдруг эти вопросы отпадут сами собой :).
              • 0
                1) Решение работает с HyperV / KVM / ESXi одновременно в том числе?

                Да. Делаются разные кластера но управляется как единое целое (Prism Central)

                2) Нет, не работаем — рынок стремительно уходит «в ноль».

                3) У нас есть BestPractices для практически любых задач. Базы данных, сервера, VDI и тд

                Например, MS Exchange на 1.4 миллиона пользователей — легко.

                longwhiteclouds.com/2014/09/28/exchange-best-practices-and-1-4million-mailboxes-on-nutanix-nx-8150/

                4) Ноды у нас можно миксовать в кластере совершенно разные (спектр от 1000 до 9000 моделей), работаем на supermicro :)
            • +2
              В общем-то, забегая вперед, привожу неполный список функционала (о котором и будет много статей).



              Поддержка ESXi / KVM / HyperV

              Централизованное управление из единой точки множеством кластеров (включая на разных гипервизорах — например ESXi и KVM)

              Апгрейд ПО «на лету» без остановки сервиса

              Расширение и уменьшение кластера без остановки сервиса (добавление или удаление нодов)

              Дедупликация — «на лету» и отложенная (по всему кластеру)

              Сжатие — «на лету» и отложенное

              Встроенное Disaster Recovery (по любой топологии, включая many to many)

              Встроенный metro cluster до 400км (синхронная репликация) с конфигурацией за 15 секунд

              Наличие All-Flash нодов

              Плотность виртуализации — 400+ VM на 2U стойко-места

              100000 / 50000 IOPS на блок 2U (для 1xxx / 3xxx серии)

              Встроенный тиринг данных (холодный / горячий уровень)

              Поддержка VAAI/VCAI для ESXi и ODX аккселерации для HyperV

              Локализация ввода-вывода (данные перемещаются вслед за VM)

              RESTful API

              Встроенное управление KVM



              И многое, многое другое ;)
              • 0
                Ну что тут можно сказать :). Ждем-с с нетерпением. Всегда интересно посмотреть «как оно под капотом?».
                • –1
                  «Под капотом» красиво, одна из причин почему я ушел в Nutanix — полное понимание грамотности архитектуры.

                  p.s. как я понимаю ребята из EMC зашли и начали минусовать даже простое перечисление функционала :) Только что выиграли у них очень большой контракт в США.
            • 0
              угадайте как называется наше решение для управления KVM

              Какое-нибудь NVM, NDVM, Nut-VM, NKVM или типа того.
            • 0
              Спасибо за введение. Ждем deep dive статей. Nutanix Controller VM (CVM)?
              • +2
                Да, Controller VM

                Вся логика 100% вынесена в ПО и не зависит от гипервизора.

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

                Как пример — отказ VSAN, встроенной в ядро ESXi, ведет к отказу работы всего хоста. В нашем случае — мы просто перераспределяем ввод-вывод по кластеру, за счет чего можем апгрейдить все ПО «на лету» даже между major версиями (с 3.x на 4.x например).

                Насколько я знаю, практически никто так больше не делает.
              • +2
                Максим, спасибо за интересную статью.

                Интересует ваше мнение (как официального представителя) — по какие задачи не следует предлагать Nutanix? С физическими серверами — понятно, интересуют другие варианты. С ходу я смог придумать такие:
                1) Развертывание Monster VM (64 vCPU, 1 TB RAM) под задачи какой-нибудь большой-большой СУБД или ERP системы. Конфигурация самой старшей ноды (NX-9040), на текущий момент, слабее лимитов гипервизоров.
                2) Требование к дешевому дисковому пространство (например, для хранения бекапов или файлопомойки). В NX-8150 установлено 20 x 1 TB дисков, классическая архитектура с какой-нибудь JBOD полкой или просто дешевым массивом позволяет устанавливать более емкие 3.5" диски с большей плотностью размещения.
                3) Малый (сверхмалый :-)) бизнес или бранч-офис. У меня нет под рукой прайс-листа Nutanix, но полагаю, что для небольшого бранч-офиса купить 2-3 обычных сервера и выделенный массив или дисковую полку, подключаемую по SAS, выйдет дешевле, чем купить NX-1020.
                4) Использование Infiniband и всевозможных ускорителей (NVIDIA Tesla, Intel Xeon Phi).

                Что вы думаете по поводу приведенных выше примеров? Возможно что-то еще?
                • +1
                  1. В данный момент лимит узла Nutanix 512Гб, в конце года будет релиз на базе Dell 720XD, который сейчас уже поддерживает 768Гб.
                  «Проблема» с объемом памяти для ВМ скорее связана с числом слотов в сервере, а не архитектуре Nutanix.
                  Много ли серверов 2U, которые имеют более 24 слотов?
                  При большом числе хостов, можно купить только софт Nutanix и использовать его на серверах например с 4 процессорами и которые будут иметь более 24 слотов — сможете выдать такие параметры для своей Monster VM.
                  2. Никто и не спорит, что для задач где вообще не требуются вычислительные ресурсы (архив например), Nutanix будет не так хорош в ценовом плане, ведь Nutanix (говоря о коробке, а не только софте внутри нее) это не только SDS, но и Compute.
                  3. Рекомендованная цена на 1420 около 60к, на минимальную конфигурацию 1320 около 45к. С учетом скидок цена может быть более-менее сравнимая (3-5к за один сервер, 10-15 за СХД), а функционал более богатый. Для SMB может оказаться и не так интересно, для ROBO с возможностью централизованно управлять всеми кластерами и при необходимости организовать DR вполне интересное решение
                  4. Модель с Nvidia GRID уже есть — 7110, вполне возможно Dell XC в конце года все это сможет обеспечить.

                  Есть ли хоть один вендор, который гарантирует для работы VDI производительность N виртуальных машин и при недостаточной мощности предоставляет бесплатно дополнительное оборудование?
                  www.nutanix.com/nutanix-vdi-assurance/

                  • 0
                    На самом деле не только Dell, наши некоторые модели уже могут принимать 768Гб (например NX-8000)
                  • 0
                    1) Если у вас ест конкретный клиент на giantic VM с конкретным проектом, обращайтесь. У нас есть что предложить ;)

                    Мы не все модели публично показываем. Намек — мы можем работать на любом количество сокетов.

                    2) NX6020 — 2U, 40TB места

                    3) Сравнивать три сервера и простую СХД vs Nutanix сложно по функциональности но не цене.

                    Мы не скрываем особо GPL, 1020 «под ключ» — GPL 40$k. Понятно, что в зависимости от объема проекта бывают существенные оптимизации.

                    4) Infiniband не нужен уже чаще всего, наши партнеры Arista Networks делают коммутаторы с 320нс задержек.
                    K1/K2 поддержка полная (7000-я серия), но для научных вычислений они слабо подходят — память не та.

                  • +1
                    Окей, полстатьи занимает теория о распределенной файловой системе. Было стойкое ощущение, что вы рассказывали про HDFS. Лично я так и не понял, чем ваш продукт отличается от экосистемы Hadoop — бесплатной, оттестированной и используемой повсеместно.
                    • +1
                      У хадупа другие задачи и возможности, впрочем, авторы статьи могут сами перечислить различия. Экосистема Nutanix довольно близка к нам (Flops), где-то он существенно нас превосходит (в плане интеграции протоколов хранилищ и локализации данных), где-то наш стек умеет то, что в nutanix не реализовано вообще (SDN, к примеру).
                      • 0
                        «nutanix не реализовано вообще (SDN, к примеру)»

                        ждите официальных новостей. напоминаю, наш глобальный партнер — Arista Networks.

                        и кстати наше KVM решение полностью управляет сетью тоже. :)
                        • 0
                          KVM — это Kernel Virtual Machine или у вас продукт так одноименно называется?
                      • –1
                        Вы просто упустили главную идею — HDFS это только для Hadoop, наше решение — для виртуализации любых масштабов и всех основных гипервизоров.

                        Вы не можете поверх HDFS крутить ничего кроме bigdata.

                        Ну и чисто по скорости — при mapreduce тестах, просто подменой HDFS на NDFS ускорение в разы (это буквально).
                      • 0
                        Конечно замечательно, что без «маркетингового пустословия», но статья получилась похожая на набор технических фактов не объединённых общим смыслом и идеей. В итоге в голове ничего не отложилось.
                        Надеюсь статьи с техническими деталями, будут более цельными т.к. продукт ваш интересный, то технических деталей хочется знать побольше.
                        • 0
                          Цель конкретной статьи — просто поверхностное введение.

                          Первая техническая статья (которая снимет очень много вопросов) будет уже на этой неделе.
                        • 0
                          А кто ЦА продукта?
                          • 0
                            1) Все что выше Small Business
                            2) Сервис провайдеры
                            3) Облачные провайдеры
                            4) Большие интернет проекты (изредка но есть).

                            • 0
                              А что насчет Openstack? Он по сути придуман для того же самого, но его вы как-то обошли стороной.
                              • 0
                                Придуман-то он придуман, но мы все знаем как реально обстоят дела. IBM насколько я знаю вообще закрыли это направление — слишком много проблем.

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

                                Мы работаем над своей версий Openstack (поверх Acropolis), будет в следующем году (весьма скоро).
                                • 0
                                  Дополнительно, опенстак никоим образом не решает проблему хранения данных — это чисто инструмент да оркестрации и различных *aaS

                                  Cinder — весьма неуклюж, нет поддержки протоколов акселерации СХД (аналога VAAI). Собственно, это основная проблема почему сейчас OpenStack поверх Nutanix неэффективен.

                                  Мы делали патч Cinder и передавали в Mirantis, но позднее решили что сами сделаем свою реализацию Openstack (Mirantis не оказался для нас надежным партнером).

                                  Как итог: в общем-то Nutanix пересекается с OpenStack (и чем дальше тем больше) но закрывает вопросы с самого низа — начиная с оборудования, заканчивая оркестрацией VM (в системе управления KVM).

                            • +1
                              Хорошая вводная статья, ждем продолжения и подробностей. Как мне кажется, BigData — это довольно специализированная область, где необходима быстрая постоянная обработка большого объема данных «здесь и сейчас». Но иногда стоит вопрос вопрос простого хранения данных. Так что традиционные СХД все равно останутся, но в этой области их потеснят безусловно, ну они и не создавались для BigData.

                              Также есть ряд практических и общих вопросов/нюансов по тексту:

                              1) Как решается вопрос резервирования данных на уровне ноды?

                              «стартовать с определенного количества ресурсов (в нашем случае — 3 узла / нода / сервера)»

                              2) Три ноды — это уже с учетом fault tolerance? Если да, то получается 2 рабочие ноды и одна «запасная», так? Если нет, то сколько еще нужно standby нод для реальной минимальной конфигурации?

                              3) Какова максимальная конфигурация вашего кластера (количество нод, суммарная емкость дисков и суммарная полезная емкость)? Какова максимальная полезная емкость одной вашей ноды?

                              «после отказа жесткого диска на 4TB, восстановление целостности»
                              +
                              «Сколько времени будет перестраиваться большой массив (скажем на сотни терабайт) и RAID 6»

                              4) На мой взгляд не очень корректное сравнение.

                              Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
                              или
                              Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?

                              «Современные процессоры Intel умеют очень многое, причем очень быстро.»

                              5) Почему же тогда для вычисления тех же самых биткойнов люди делали специальные процессоры или использовали FPGA?
                              Обычный процессор умеет многое и быстро, если грамотно написан софт. Но все же спец.железка, заточенная под определенную функцию будет быстрее.

                              да, SLA 100% реален

                              6) Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?
                              • 0
                                Cпасибо за очень интересные вопросы по существу.

                                «Так что традиционные СХД все равно останутся, но в этой области их потеснят безусловно, ну они и не создавались для BigData.»

                                наше решение далеко не только для bigdata, но для хранения и работы с совершенно обычными данными. мы просто работаем по принципам bigdata.

                                1) «Как решается вопрос резервирования данных на уровне ноды?»

                                На уровне ноды — никак, все диски независимы и каждый просто смонтирован локально по ext4
                                Данные именно что «размазываются» по кластеру, и всегда есть помимо локальной копии — еще 1 или 2 копия на других нодах кластера

                                Это node awareness (у нас есть еще block awareness и скоро будет rack awareness).

                                2) «Три ноды — это уже с учетом fault tolerance?»

                                Да, это уже отказоустойчивый кластер — любой элемент (диск, или нода целиком) может выйти из строя и датастор будет доступен. Потери данных при этом не будет.

                                Поэтому наша минимальная конфигурация 1320 идет как раз с 3-я нодами стартово.

                                3) " Какова максимальная конфигурация вашего кластера"

                                У нас есть ноды по 6.4TB flash + 20TB SATA, итого 26.4TB RAW места с тирингом.
                                Именно на них например запускают очень крупные базы данных.

                                Полезное место соответственно при RF2 будет около 12.5TB на каждую ноду.

                                www.nutanix.com/2014/08/13/nx-8000-series/

                                Максимальной конфигурации — лимита не существует, Cassandra — есть в мире инсталляции на тысячи серверов.

                                В реальных условиях я видел кластера на сотни серверов на Nutanix, далее просто начинают делить на части по принципу «не класть все яйца в одну корзину».

                                4) «Либо первое и Сколько будет перестраиваться диск на 4TB в RAID6?
                                или
                                Либо второе и Сколько будет перестраиваться RAIN на сотни терабайт?»

                                Если честно, не понял некорректности.

                                Пример приведенный (там есть ссылка) — 32 ноды 6020, каждая из которых 20TB. Итого — 640 терабайт.

                                Берем RAIN решение на 640TB и берем RAID6 на 640TB (говорим о RAW).
                                Сравниваем время ребилда после вылета одного диска на 4TB.

                                Оно будет кардинально отличаться, на такой размер массива может быть около суток для RAID системы.

                                5) «люди делали специальные процессоры»

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

                                В добавок, если бы Intel сделал аппаратную поддержку «обсчета биткоинов» в процессоре — FPGA был бы не нужен.

                                Как пример, есть компания которая является неким псевдоконкурентом нам (Simplivity).

                                Они сделали плату аппаратную для сжатия и дедупликации.

                                Cухой итог — простой IOmeter тест заваливает I/O запросами эту плату и все просто «валится», потому что уходит в ПО.

                                6) «Звучит как будто вы создали вечный двигатель :) Вы гарантируете, что железо собрано на заводе без технолгических отклонений? Что софт написан без единой ошибки?»

                                Мы сделаны так (акцентировано в статье), что можем выдерживать множественные одновременные отказы оборудования.

                                Например, в случае с Block Awareness и 3+ блока в кластере, целиком один блок (4 нода). Если у вас есть Metro Cluster — то 8 нод одновременно (из 24).

                                По поводу ПО — ошибки безусловно бывают, но тут как раз вопрос правильного резервирования.

                                У нас поддерживается DR (Disater Recovery) на множественные датацентры (many to many).

                                Опыт показывает, что SLA сильно больше 5 девяток, при правильном дизайне архитектуры, в нашем случае вполне возможен (если буквально — не было ни одного отказа системы и потерь данных) — мы не скрываем, что один из самых крупных клиентов компании это правительство и военные США (включая ВВС и многие другие подразделения c названиями из 3 букв ;) ).

                                Собственно, это одна из причин почему на рынки Европы начали выходить достаточно поздно.
                                • 0
                                  Мы сделаны так (акцентировано в статье), что можем выдерживать множественные одновременные отказы оборудования.

                                  Отказы вида «умер диск», «выдернули питание» и так далее — скучные отказы, от них слишком легко защититься. И конечно маркетологи от вендоров всеми силами стараются закрыть глаза на то, что бывают и другие фейлы, при которых сервис встает колом, но все компоненты при этом вроде как пингуются…

                                  Напомнить, что и у многократно восхваляемого в статье гугла случались фейлы, причем с потерей данных, причем сразу на много процентов пользователей? :)
                                  Amazon вообще относится к так называемым "udp cloud" (нравится мне этот термин). Его инфраструктура не является надежной. Это не является проблемой, если сбои нормально обрабатываются вышестоящим приложением.

                                  А Nutanix — «udp хранилище»? Традиционные массивы — скорее «tcp».
                                  Если коротко, то на 2U cтойко-места (Nutanix NX-3461 например) вы «выжимаем» около 120.000 IOPS на чтение, и более 50.000 IOPS на запись.

                                  Есть, кстати, такой производитель флеш-массивов как Violin, там цифры почти на порядок выше в пересчете на юнит.
                                  • 0
                                    Тут стоит упомянуть 2 аспекта.
                                    Первое — именно что Violin — это flash-массив. То есть, если не ошибаюсь, какое-то сравнение может быть с 9000й серией Nutanix. Максим, есть ли данные хотя бы в тех же iops-попугаях по 9000й серии?
                                    Ну и второе — «немного» разные цены. Нолик к цене Nutanix 900й серии просто смело рисуем (в реальности больше, а на поддержку у Violin вообще конские цены), хотя да, вопрос — кому что надо — денег потратить (такое бывает) или работу работать :)
                                    • 0
                                      9000-я серия будет сильно быстрее в пересчете IOPS на юниты, в ней 2 нода в 2U и суммарно 12 SSD дисков по 1.6 терабайта.

                                      Я лично еще не щупал (не зря она называется Ferrari), но предполагаю как минимум двухкратный прирост.

                                      Запрошу сегодня у коллег в Калифорнии.
                                    • 0
                                      «Отказы вида «умер диск», «выдернули питание» и так далее»

                                      согласен.

                                      поэтому мы держим для sync кластера отказ 8 нодов (вместе со всеми дисками) из 24-х, предусмотрели множественный DR и прочее. да, это решается как раз не надежностью оборудования но множеством уровней резервирования данных.

                                      " многократно восхваляемого в статье гугла случались фейлы"

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

                                      Идеальный термин «udp cloud». Cпасибо, будем использовать. Ибо это про нас.

                                      «Его инфраструктура не является надежной. » мы являемся именно таким решением, ибо у нас вся логика на app уровне (еще раз — 100% программное решение).

                                      Прямо сейчас идет тендер Росатома ( zakupki.rosatom.ru/1410020528906 ) на Nutanix + Arista, где коллеги сообщили что очень устали от безумных цен на Viloin. Который при этом является просто очень быстрой традиционной RAID-флеш коробкой.

                                      В пересчете IOPS / $$$ мы кардинально выигрываем у Violin, тем более что помимо СХД / SSD вы получаете сразу очень много мощностей (процессоры и память).

                                      Именно поэтому Nutanix оценочная стоимость сейчас около 2-х миллиардов долларов и бурно растет, а Violin — на грани банкротства.

                                      blogs.barrons.com/techtraderdaily/2014/04/17/violin-after-58-collapse-new-chief-denuccio-has-high-hopes-for-enterprise-growth-besting-emc/

                                      • 0
                                        поэтому мы держим для sync кластера отказ 8 нодов (вместе со всеми дисками) из 24-х, предусмотрели множественный DR и прочее

                                        А всякие сценарии split brain, рассинхронизации, торможения всего кластера из-за торможения (но не полного падения) одной ноды и прочее? С участием (или по вине) багов в вашем ПО?
                                        случались, ибо они первопроходцы собственно

                                        Ну последний фейл гмейла был не так давно…
                                        мы являемся именно таким решением, ибо у нас вся логика на app уровне (еще раз — 100% программное решение).

                                        Нет-нет. Для того же приложения VMWare вы — черный ящик, инфраструктура. Наравне с любым классическим массивом.
                                        • 0
                                          «А всякие сценарии split brain, рассинхронизации, торможения всего кластера из-за торможения (но не полного падения) одной ноды и прочее?»

                                          Еще раз — доступно multi-site DR. Резервирование одного ДЦ на два других ДЦ например может быть, причем на разных версиях железа и ПО (чтобы как раз обезопаситься от проблем в новом ПО)

                                          «Ну последний фейл гмейла был не так давно…» если у них не было доп. копий данных, то вы их можете спокойно делать — столько, сколько нужно. metro cluster, DR, snapshots (локальные и удаленные) и тд.

                                          Поэтому и нужны грамотные архитекторы. Nutanix — это просто очень мощный и один самых надежных на сегодня инструментов, но головы человека не отменяет :)

                                          «Для того же приложения VMWare вы — черный ящик, инфраструктура»

                                          А причем тут VMware? Мы кстати с vcenter не работаем вообще, а работаем с SDK каждого хоста напрямую. поэтому от проблем vCenter защищены кстати.

                                          Да и не то чтобы «черный» — VAAI / VCAI поддержка.

                                          Так вот — мы сделали свое KVM управление, которое для многих вообще заменит ESXi / vCenter. Там мы вообще имеем 100% контроль над происходящим.

                                          Презентация решения будет сделана на HighLoad, можно приходить. Но в принципе суть уже описана тут:

                                          www.highload.ru/2014/abstracts/1645.html

                                          • 0
                                            доступно multi-site DR

                                            Безумно дорого в плане каналов и все равно наверняка без гарантии консистентности (вы же не волшебники?). Хотя это в любом случае надо делать. Но стараться свести вероятность применения сценария DR поближе к нулю.
                                            если у них не было доп. копий данных, то вы их можете спокойно делать — столько, сколько нужно. metro cluster, DR, snapshots (локальные и удаленные) и тд.

                                            Они данные с лент восстанавливали… И я уверен, что у них умные люди тоже много чего наворотили. Но отказ был именно со стороны подсистемы хранения данных.
                                            а работаем с SDK каждого хоста напрямую.

                                            Ну то есть грубо говоря виртуалка все равно монтирует в качестве диска LUN, который хранится на ваших системах. Общение вроде по NFS происходит? Ничего особо не меняется.
                                            поэтому от проблем vCenter защищены кстати.

                                            Не припомню у коллег ни одной связанной с vCenter проблемы. VMWare вообще любят за стабильность.
                                            мы сделали свое KVM управление

                                            Когда я последний раз проверял, KVM по функционалу существенно отставал от vSphere.
                                            • 0
                                              «все равно наверняка без гарантии консистентности»

                                              Metro Cluster — по опеределению дает гарантии консистентности, ввиду синхронности. Да, больше никто из вендоров не умеет делать метро кластера на 400км.

                                              Наш DR (асинхронная репликация) — поддерживает consistency groups: группы VM которые надо снимать снапшоты одновременно. Мы не работаем per-LUN, у нас нет этого, защита ведется именно per-VM.

                                              По поводу каналов (помимо того что они стоят уже смешных денег — 10 гигабит из Мск во Франкфурт можно взять за 10-15$k) — мы передаем дельты снапшотов в сжатом виде, что является крайне эффективным способом.

                                              «был именно со стороны подсистемы хранения данных.»

                                              поэтому надо делать DR / снапшоты, причем не на ленту. Никто не идеализирует гугл, очень большая компания работающая на B2C рынок. Но основные принципы именно они продвигают.

                                              Мы заточены под B2B и для нас вопрос сохранности данных — ключевой.

                                              «ни одной связанной с vCenter проблемы.»

                                              Значит ваши коллеги эксплуатируют небольшие кластера.

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

                                              Кстати, совсем недавно была критическая бага в очередном апдейте ESXi, которая затронула сотни тысяч инсталляций по всему миру. Фактически, для многих это было катастрофичной проблемой.
                                              Фиксили ее около 2-х (!) месяцев.

                                              kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076392



                                              Гхм. KVM == ESXi, Acropolis == vShpere

                                              Так что мне не очень ясно как можно сравнивать гипервизор с системой управления оным :)

                                              И да, многие вещи мы уже делаем намного лучше чем vShpere (тот же DR который заменяет SRM), а многие — вообще уникальны (как Metro Cluster на 400км)
                                              • 0
                                                Metro Cluster — по опеределению дает гарантии консистентности, ввиду синхронности.

                                                Ну тогда ждем описания, как оно работает.
                                                мы передаем дельты снапшотов в сжатом виде, что является крайне эффективным способом.

                                                Но на канал все равно будет обрушиваться нагрузка, сравнимая с нагрузкой на запись на диски.
                                                А то, что было записано после снятия снапшота и до снятия следующего снапшота, безвозвратно потеряно в случае сбоя?
                                                Значит ваши коллеги эксплуатируют небольшие кластера.

                                                Вроде сотни хостов суммарно… Не слишком много, но и не мало.
                                                vCenter имеет множество очень существенных ограничений — максимальный размер кластера 32 нода (что в общем-то уже даже не смешно), ограничение по максимальному количеству VM и прочее.

                                                А куда вам сильно больше?
                                                К одному vcenter'у можно и тыщу хостов подключить.
                                                KVM == ESXi, Acropolis == vShpere

                                                ESXi как бы не существует. Теперь он vSphere Hypervisor вроде бы. А vCenter управляет ими.
                                                многие вещи мы уже делаем намного лучше чем vShpere (тот же DR который заменяет SRM), а многие — вообще уникальны (как Metro Cluster на 400км)

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

                                                  Я надеюсь есть понимание того что такое дельта снапшота? раз в 15 минут скажем снимается снапшот очередной, причем только изменившиеся данные на VM. далее — передается только это изменившаяся часть, которая еще и сжимается на лету.

                                                  Объем передаваемых данных в сумме — кардинально ниже посравнению с «нагрузкой на запись на диск».

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

                                                  Мы работаем с задержками до 5 миллисекунд, что позволяет говорить о ~400км.

                                                  «К одному vcenter'у можно и тыщу хостов подключить.»

                                                  Нет, это неверно. Точнее подключить можно, работать это нормально не будет. Проблема именно в том что начинаются проблемы с централизованными SQL базами. Да, можно наворотить Oracle RAC кластер — но это будет стоить как космолет. И требует серьезного обслуживания.

                                                  Простой момент — если начать дергать метрики VM нужные из vcenter, он просто падает, в случае хотя-бы нескольких тысяч VM. Именно поэтому мы берем всю информацию напрямую из SDK хостов.

                                                  «ESXi как бы не существует. „

                                                  Как бы это ошибочное заявление :)

                                                  “Free VMware vSphere Hypervisor, Free Virtualization (ESXi…
                                                  www.vmware.com/uk/products/vsphere-hypervisor
                                                  Get started with virtualization for free with the VMware vSphere Hypervisor ( based on ESXi), a bare-metal hypervisor.»

                                                  «можете делать репликацию и на другое полушарие „

                                                  Работает, причем прекрасно. Собственно на VMworld показывали репликацию между Брюсселем и Калифорнией (Сан-Хозе). Собственно, я не вижу причин никаких почему это не должно работать.

                                                  • 0
                                                    Get started with virtualization for free with the VMware vSphere Hypervisor ( based on ESXi), a bare-metal hypervisor.»

                                                    Так сейчас маркетологи переименовали ESX в vSphere Hypervisor. Но пока, чтобы народ совсем с ума не сошел, упоминают, что это одно и то же.
                                                    Собственно на VMworld показывали репликацию между Брюсселем и Калифорнией (Сан-Хозе).

                                                    Так речь про синхронную репликацию? Если, допустим, мы говорим про процессинг, то потеря 14 минут транзакций — жопа эпических размеров.
                                                    • 0
                                                      «переименовали ESX в vSphere Hypervisor»

                                                      Не видел объявлений о переименовании, речь идет о том что Sphere Hypervisor базируется на ESXi

                                                      «Так речь про синхронную репликацию?»

                                                      Речь и про то и другое. В зависимости от задач.

                                                      Для процессинга делается синхронный кластер, что логично. Там RTO — секунды. Между Брюсселем и Амстердамом работает отлично (у нас там очень крупные банки-клиенты), расстояние около 300км.

                                                      Для множества других задач — хватает RTO 15 минут и даже выше (очень часто вижу требования 30 минут или час).

                                                • 0
                                                  Ну и заодно:
                                                  10 гигабит из Мск во Франкфурт можно взять за 10-15$k

                                                  Гонять реплики СХД через интернет-канал? Под такое и провайдерские L2 каналы не очень годятся, нужна темная оптика или хотя бы лямбда DWDM. И возникают вопросы вроде «как вы переживаете потери, разрывы соединений между кластерами и прочее?».

                                                  А волокно длиной 400км — довольно дорого.

                                                  Примеры гуглов, которые, возможно, гоняют реплики через интернет, приводить не надо. Кто знает, на что они договорились с провайдерами? У нас доступность любого интернет-канала и на две девятки не тянет, а уж периодические проседания в разных направлениях — норма. Хотя возможно, что те, кто не мониторят это, со мной не согласятся.
                                                  • 0
                                                    Нам не нужен L2.

                                                    Нам хватает L3. И да, асинхронная репликация прекрасно работает и в первую очередь затачивалась на рынок (госструктур || военных) США. Репликация между Майями и NY — совершенно нормальное дело, а это тысячи км.

                                                    Доступность каналов — не стоит сгущать краски, у RETN например все прекрасно работает без проблем годами.

                                                    Ну и никто не мешает (ввиду того что нам L3 хватает) использовать несколько каналов одновременно.

                                                    И да, репликация работает даже через ssh туннель и http прокси. (!).
                                                    • 0
                                                      у RETN например все прекрасно работает без проблем годами.

                                                      Ну а я сейчас пытаюсь доказать провайдеру в районе Кавказа, что у него проблемы на магистрали — у меня несколько десятков точек у разных провайдеров имеют около 5% потерь до наших AS, и во всех случаях трафик ходит через того несчастного провайдера. Бои идут с переменным успехом. Никто никому ничего не обязан. Скоро останется крайний вариант — в свои анонсы коммьюнити насовать, чтобы пойти в обход того провайдера. Но нет гарантии, что это поможет.

                                                      Вот с L2VPN/L3VPN каналами проще, там если есть проблема — сразу есть на кого катить бочку, и проблема быстро устраняется.
                                                      Ну и никто не мешает (ввиду того что нам L3 хватает) использовать несколько каналов одновременно.

                                                      Конечно ничто не мешает. Но надо очень тщательно их мониторить и очень быстро их фейловерить. Тут уже нужен тот самый «sub-second convergence», а низя, если будут сравнительно небольшие потери, те самые 5-10% к примеру, которые практически прибьют TCP обмен, но при этом не приведут к стабильной потере кипалайвов чего угодно.
                                                      • 0
                                                        Небольшие потери нам не сильно страшны — это L3 / tcp, будут просто ретрансмиты.

                                                        Ну и надо использовать правильные технологии — типа www.talari.com

                                                        Там все мониторится и отрабатывает на полном автомате, прозрачно для клиента.
                                                        • 0
                                                          Небольшие потери нам не сильно страшны — это L3 / tcp, будут просто ретрансмиты.

                                                          0,1% очень сильно просаживает скорость, в несколько раз (проверено эмпирически).
                                                          5% может почти парализовать обмен.
                                                          Ну и надо использовать правильные технологии — типа www.talari.com

                                                          Смотрим топовую железку:
                                                          T5000H: designed for large data centers and call centers, T5000H supports aggregation of WAN bandwidth up to 3 Gbps uplink/3 Gbps downlink (3 Gbps full-duplex)

                                                          Вопросы?

                                                          Нет, есть, разумеется, тот же Cisco ASR1k с PfRv3, где обещают обнаружение brownout за 2 секунды по анализу data plane трафика, и где скорости повыше будут… Но не тестировал, ничего сказать не могу. PfRv2 был уродцем, стонавшим «kill me».
                                                          • 0
                                                            «5% может почти парализовать обмен.»

                                                            Пардон, это совершенно неверно.

                                                            мы в Badoo.com синхрили (и сейчас синхрят) очень большие объемы данных, Майями-Прага. Там потери бывают очень немаленькие.

                                                            Стек на линуксе можно очень гибко настраивать.

                                                            «Вопросы?»

                                                            3 гигабита — это 250 мегабайт в секунду. Это что, мало???? Пардон, если нужно больше — это явная ошибка разработки архитектуры ПО.
                                                            • 0
                                                              3 гигабита — это 250 мегабайт в секунду. Это что, мало????

                                                              Для канала между нагруженными датацентрами? Ну вообще-то немного (если вы не Амазон и вам не наплевать на DR). А выше речь вообще шла про 10G линки…

                                                              250 мегабайт в секунду — это как пара хомячковых жестких дисков на 7200 оборотов.
                                                              Пардон, если нужно больше — это явная ошибка разработки архитектуры ПО.

                                                              Есть ПО, которое само по себе — одна большая ошибка. Но оно приносит конторе деньги. Большие деньги. Позволяющее покупать и те крутые сервера за лямы долларов, и крутые массивы. А сравнительно кратковременный (10-20 секунд, причем эта цифра даже не от таймеров TCP берется) сбой связи между компонентами ПО может привести к часовому даунтайму из-за необходимости рестартовать много-много разных систем, которые ну очень медленно поднимаются, а пока они рестартуют — бизнес частично или полностью стоит. И ни черта с этим не сделаешь. Опять же, кто работал в финансовом секторе, тот знает. Я с этим, к счастью, не сталкивался, но многие вынуждены и L2 между датацентрами протягивать. Да, на цискин OTV много покупателей, и далеко не все из них безумцы. Где-то это позволит обойти ущербность ПО и не остановить бизнес при попадании метеорита в основной датацентр. А кто-то даже таскает ВМ между датацентрами без смены адресов (есть разные мерзкие системы, отлично виртуализирующиеся, но при генерации лицензии учитывающие IP адрес)…
                                                              • +1
                                                                Для передачи изменений снапшотов со скоростью 250 мегабайт в секунду требуется очень огромное количество операций, которые могут позволить очень большие организации. Для них уже и требования к каналам связи будут больше и соответственно они будут готовы заплатить за эти каналы и большие деньги.
                                                                По поводу лицензий, которые учитывают IP адреса, никто не мешает использовать виртуализацию сети или же оркестрацию, когда основной ЦОД не отвечает — меняется маршрутизация на существующее адресное пространство в другой ЦОД.
                                                                • 0
                                                                  Причем тут канал между нагруженными датацентрами, мне не очень понятно.

                                                                  Очевидно, что metro cluster делается только для необходимых приложений.

                                                                  И для них 250 мегабайт в секунду — более чем достаточно.

                                                                  Если недостаточно — ставить еще железок.

                                                                  У нас как-то плавно все сошло к обсуждению сетевых вещей, которые на самом деле совершенно вторичны.
                                                    • 0
                                                      Про «мы одни умеем синхронно и на 400 км» я не стал бы так категорично утверждать, во избежание казусов :-).

                                                      Тут еще вопрос какая задержка на кананале должна выдерживаться при таких дистанциях? Раньше на более коротких отрезках говорили про round-trip time time 5ms. Сейчас с увеличением дистанций все чаще говорят про round-trip time 10ms.
                                                      • 0
                                                        Всегда рад научиться новому и признать если где-то неправ был.

                                                        Если не сложно, подскажите другое решение (СХД или конвергентное) enterprise-уровня с репликацией на ~400км (5 мс).

                                                        Возможно, что-то упустили.
                                                        Насколько я знаю, Netapp и EMC — 100 и 200км максимум.

                                                        Реально нам не проблема и больше сделать, но 10мс — это уже too much для синхронного датастора, latency записи на диск будет совсем уже грустной :)

                                                        p.s. правило простое — 0.25мс на каждые 100км (если идеальный линк L2). роутеры и прочее конечно-же сильно прибавляют.
                                                        • 0
                                                          Вы используете TCP транспорт для этих целей или что-то иное? RTT в 5мс будет очень сильно ограничивать возможности синхронных операций для профиля нагрузки с резкими всплесками записи, так что эта затея по большей части малореальна на приличном ио из-за фундаментальных лимитаций.
                                                          • 0
                                                            TCP но с тюнингом стека.

                                                            Всплески нагрузки не так важны как раз пока не уперлись в полосу, у нас есть oplog в который уходит I/O (на SSD), будет задержка с подтверждением операции ввода-вывода в ОС (soft updates, гарантированная запись данных).

                                                            Если правильно настроить работу виртуальных SCSI / SAS адаптеров в ОС (включая размер очереди) — работает все весьма прилично, мало того адаптеров можно делать много для парралелизации (а далее объединять на уровне ОС чем-то вроде LVM)

                                                            5мс протестировано и признано вполне рабочим, можно было и больше но там как раз уже начинает сильно сказываться.

                                                            На забывайте, что мы не блочном уровне оперируем, а на уровне логических объектов (контейнеров) для Metro.

                                                            Вот (поверхностное) описание Metro:

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

                                                            По поводу oplog:

                                                            image
                                                            • 0
                                                              > TCP но с тюнингом стека.
                                                              Расскажите, пожалуйста, про методики и/или рекомендации такого тюнинга.
                                                              • 0
                                                                Никаких «ноу-хау» тут нет.

                                                                Много вещей еще на Badoo.com в свое время отлаживали для межконтинентальной репликации, скорость в десятки раз поднимали.

                                                                1) Размер окна приемо-передачи
                                                                2) SACK
                                                                3) Правильный алгоритм congestion-control
                                                                4) Параллельные потоки
                                                                5) и тд. — еще с пару десятков параметров наберется.

                                                                Гугл выдаст пачку ссылок :)

                                                                sites.google.com/site/tfsidc/superfast-networking
                                                                www.taos.com/2012/08/01/optimizing-long-haul-tcp-throughput/
                                                                etc
                                                                • 0
                                                                  Еще один момент — не припоминается ни один LFN-оптимизированный алгоритм, который бы подошел к этой задаче на сто процентов. Это не к вопросу о вытягивании нюансов, просто интересно, существующий используется или свой.
                                                                  • 0
                                                                    Это безусловно верно, 100% алгоритмов не бывает.

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

                                                                    В любом случае, если встают специфические вопросы — у нас есть «под капотом» сотни параметров для тюнинга и отладки, так называемые gflags

                                                                    Например, вот тут прошлогодняя статья по поводу отладки асинхронного DR

                                                                    nutanix.blogspot.co.uk/2013/09/nutanix-dr-troubleshooting.html
                                                                • 0
                                                                  Вот это собственно говоря очень важно:

                                                                  To resolve this problem, TCP Selective Acknowledgement, defined in RFC 2018, allows the receiving system to acknowledge all packets received even if an intermediate packet has not been received. This results in retransmission of only the lost packets, instead of an entire window worth of data.

                                                                  Но при этом в линуксе есть нюансы :) Зависит от версии ядра.

                                                                  fasterdata.es.net/host-tuning/linux/expert/
                                                                  • 0
                                                                    SACK поддерживается давно и, вероятно, везде. Очень странно хвастаться его наличием.

                                                                    По какой причине для такой задачи был выбран TCP? Почему не обрабатывать дропы/реордеры/прочее на уровне приложения, гоняя сервис поверх UDP? Нет, наличие SACK вовсе не означает отсутствия мощного спада пропускной способности всего потока от потери одного-единственного пакета. Просто не требуется перепосылать всё окно. Да и ни один congestion management алгоритм для TCP не сможет достичь эффективности и скорости работы собственного протокола (например, поверх UDP — неважно). И колоссального размера буфера, позволящие свести к минимуму паузы при ожидании ACK, не нужны.

                                                                    Единственное что приходит в голову — stateful файрволы любят TCP, потому что у альтернатив отсутствует понятие сессии на транспортном уровне.
                                                                    • 0
                                                                      Насчет «хвастается» — тут уже каждый видит что хочет увидеть.

                                                                      Вообще-то дословно написано — "никакого ноу-хау тут нет".

                                                                      Насчет TCP в данном случае — нет никаких причин переходить на UDP, на наших тестах и у клиентов все работает прекрасно, мало того это работает и в других компаниях (пример уже приводился — badoo.com спокойно синхрит данные между континентами разными).

                                                                      Дискуссия не имеет смысла, я понимаю что (как в анекдоте про блок / собак / кошек) каждый переводит на ту область в которой силен (в данном случае — сеть), но функциональность метро-кластера это лишь несколько процентов от того что умеет и делает Nutanix.

                                                            • 0
                                                              Давайте уточним про какие 5 ms вы пишете. В случае nutanix 5 ms это RTT (туда и обратно)? Упрощенно говоря прохождение пакета данных в одну сторону 2,5 ms и возвращение ask о записи тоже 2,5 ms, в сумме 5 ms. Или все таки имеется в ввиду по аналогии с пингом, прохождение сигнала в одну сторону 5 ms?
                                                              • 0
                                                                RTT, безусловно.

                                                                Если в одну сторону 5ms — это будет уже 10ms RTT и сильно больше 400 км.

                                                                Если очень примерно говорить, то с накладными расходами — 100км это миллисекунда RTT.

                                                                Вот кстати у Brocade вплоне неплохая статья

                                                                community.brocade.com/t5/Design-Build/Data-Center-Infrastructure-Validation-Test-FCIP-amp-Fibre/ta-p/36925
                                                                • 0
                                                                  Насколько помню, по моему «нежно любимый» вами EMC заявлял прошедшей весной о тех же максимальных характеристиках для своего решения VPLEX Metro (5ms RTT и до 400km расстояние между сайтами).

                                                                  Хотя тут все еще и от софта может зависеть. Та же VMware по-моему поддерживает растянутый HA кластер с характеристиками канала до 10ms RTT между площадками, со всеми live миграциями машин и etc.
                                            • +1
                                              Спасибо за развёрнутый ответ. Звучит все действительно очень «вкусно» и интересно.
                                              • 0
                                                Всегда рады. Надеюсь, после цикла технических статей будет реально еще больше понимания.
                                            • 0
                                              Забыл раскрыть один момент (по поводу FPGA / аппаратного ускорения vs решение в ПО).

                                              Если коротко, то на 2U cтойко-места (Nutanix NX-3461 например) вы «выжимаем» около 120.000 IOPS на чтение, и более 50.000 IOPS на запись.

                                              Это реальные и честные цифры, random I/O.

                                              10 блоков (20U, половина стойка) покажут соответственно 1.2 миллиона IOPS на чтение. И так далее (линейное расширение).

                                              Вот пример (прошлогодний, на сегодня цифры значительно выше за счет оптимизации ПО):

                                              https://www.youtube.com/watch?v=B-RBDtKgQTo&feature=youtu.be

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

                                              А взлетит или нет — посмотрим.
                                              • 0
                                                А расскажите, что же у нас пропиетарного из железа? :)
                                                Прямо интересно стало.

                                                Или даже ОС? Это ничего что на 95% это opensource, а «железо» — сервера Supermicro или Dell, причем абсолютно стандартные?
                                                И что сейчас уже made in Russia вовсю обсуждается?

                                                Насчет «взлетит» — уже взлетело, и давно.

                                                Официальные продажи последний год (в этом явно сильно лучше будет) — более 200 миллионов долларов.

                                                www.nutanix.com/2014/08/06/nutanix-closes-strong-fiscal-year-exceeds-200-million-bookings-run-rate/
                                                • 0
                                                  Посмотрел ваш профайл, стало все понятно — откуда такие странные комментарии :)

                                                  В общем-то для netapp действительно приходят тяжелые времена.

                                                  Выдержки из ваших опусов:

                                                  «Netapp — реальность против маркетинга 67
                                                  +2 mirrik,14 февраля 2014 в 14:32#
                                                  Есть полноценный QoS с ограничением по IOPS или MB/s — он доступен в cDOT.
                                                  Никакой связи в записи с объемом кэша нет — запись ведется через NVRAM, который размером в несколько гигабайт.

                                                  Про все остальное прекрасно ответил bakset.»

                                                  «FilerView уже давно нет, да и FlashCache ставится куда угодно, кроме младших моделей FAS2xxx.»

                                                  «Расскажите это NetApp. У них TP был даже тогда, когда он не назывался TP — можно было отдавать объемы большие, чем есть физически, увеличивать и уменьшать размер мета-RAID-групп (у NetApp они называются aggregate).»

                                                  • 0
                                                    Пока не докажете, что в NetApp настапают тяжелые времена — говорить, видимо, не о чем (:
                                                    • 0
                                                      Умные люди просто смотрят вперед.

                                                      1) 2017 год — 50% (или более) энтерпрайз-рынка — конвергентные системы (см. Гартнер)

                                                      2) Netapp — акции были 60$, сейчас уже 40$

                                                      3) За оставшиеся 50% рынка будут драться все традиционные вендоры, причем рынок постоянно сокращается.

                                                      4) Конторы типа EMC выживут, просто купив кого-то из производителей серверов (по рынку уже ходят слухи о HP, есть партнерства с Lenovo), для того чтобы делать конвергентные решения. Netapp — не потянет, денег намного меньше.

                                                      5) Flexpod — крайне странное образование, Cisco ведет себя как неверная жена ;) Вон уже и с Simplivity договорились. Недаром VCE будет забирать под себя EMC — на Cisco надежды мало.



                                                      Ну и после ваших крайне смешных заявлений про «пропиетарщину» — реально нет смысла учавстовать в дискуссиях ;)

                                                      • 0
                                                        А ничего, что как раз EMC по слухам продать хотят, а не ОНИ кого-то покупают? И второе: если вы не способны понять, что ваша проприетарщина на любом уровне (начиная от кластеризации и заканчивая хранением в разы) более проприетарная — чем тот же FlexPod — говорить и правда не о чем.
                                                        • 0
                                                          Ну, тут только руками развести.

                                                          Нет понимания того что не важно HP (Dell / кто-угодно) купит EMC или EMC купит часть HP / Lenovo / кого угодно — результат один, конвергентные решения.

                                                          Нет понимания того что «пропиетарщины» в Nutanix практически нет, но есть на 95% opensource и 100% описанная архитектура.

                                                          Реально, вам незачем тратить свое время на нас.

                                                          p.s. www.businessinsider.com/r-exclusive-tech-firms-hp-emc-call-off-merger-talks---sources-2014-10

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

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