Архитектура кластера Jelastic: высокоуровневый обзор системы Platform-as-Infrastructure

    В предыдущей публикации мы рассказали о новом позиционировании нашего продукта, о трансформации его в более комплексное решение Platform-as-Infrastructure, которое сочетает гибкость IaaS и удобство PaaS. В этой статье мы опишем структуру кластера Jelastic и его основные компоненты.

    Основная задача Jelastic упрощать сложные технические решения, автоматизировать рутинную работу администраторов и разработчиков. Так, к примеру, уже сегодня вы можете легко развернуть комплексные приложения написанные на Java, PHP и Ruby. Поддержка мультиязчности была изначально заложена в архитектуру Jelastic. В ближайших планах также поддержка Node.js, Python и .Net.

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

    Общая информация


    Инсталяция Jelastic Platform-as-Infrastructure — это изолированный кластер, состоящий из группы серверов и сервисов, которые взаимодействуют как целостная система, предоставляя возможность удобно разворачивать, тестировать, поддерживать и масштабировать приложения в продакшине.

    Кластер Jelastic состоит из физических серверов, на которых размещены виртуальные изолированные контейнеры, выделенные под пользовательские окружения, и управляющего сервера для внутренних системных сервисов.

    архитектура кластера Jelastic


    Управляющий сервер


    Управляющий сервер — содержит набор внутренних компонентов для управления ресурсами, обработки запросов, анализа активности пользователей и всеобщей поддержки кластера Jelastic. Обычно, мы рекомендуем использовать отдельный выделенный сервер, так как это предоставляет более высокий уровень стабильности и работоспособности. Компоненты управляющего сервера отвечают за:
    • Выделение необходимых ресурсов (provisioning)
    • Настройку шаблонов (кластеризация, балансировка нагрузки, прочее)
    • Управление жизненным циклом приложений
    • Развертывание приложений
    • Масштабирование приложений
    • Обработку пользовательских запросов через общий резолвер
    • Логи и статистику
    • Биллинг
    • Инструменты бизнес-аналитики
    • Мониторинг и проверку работоспособности

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

    Инфраструктурный слой


    Jelastic относительно не привередлив к базовым ресурсам и может быть установлен как на голое железо, так и на такие IaaS решения как OpenStack, AWS Amazon, Azure, Rackspace и другие.

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

    Физические сервера или же большие виртуальные машины (виртуализированные с помощью KVM, ESXi, Hyper-V и т. д.) в дальнейшем дробятся на небольшие изолированные виртуальные контейнеры. Набор таких контейнеров со всеми необходимыми для определенного приложения стеками образует пользовательское окружение.

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

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

    изолированные виртуальные контейнеры

    Виртуализация контейнеров


    Jelastic использует Parallels Virtuozzo Containers, что позволяет добиться очень хорошей плотности по количеству контейнеров на одном физическом сервере. Это достигается за счет использования виртуализации на уровне операционной системы.

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

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

    Стоит отметить, что Jelastic является первой платформой, которая начала использовать полноценную контейнерную виртуализацию с первых дней. Наши ближайшие конкуренты OpenShift и CloudFoundry уже по одному разу перепроектировали свои решения внедряя слой псевдо-контейнерной виртуализации cgroups + SElinux и Warden соответственно. В ближайшем времени их ждет еще один этап редизайна архитектуры, в котором они уже будут немного ближе к текущему решению Jelastic — обе платформы мигрируют на Docker. Однако даже при этом Jelastic будет обладать рядом важных преимуществ — более качественная изоляция контейнеров при такой же эффективности утилизации ресурсов, наличие живой миграции, а также бесценный трехлетний опыт использования контейнеров внутри платформы.

    Высокая доступность для приложений


    Одной из функциональных особенностей является равномерное распределение контейнеров одного окружения по разным физическим серверам. Это достигается с помощью anti-affinity правил, которые регулируют распределение контейнеров по кластеру таким образом, что контейнеры одного окружения по возможности не попадают на один и тот же физический сервер.

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

    Живая миграция


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

    живая миграция

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

    Режим гибернации (режим “сна”)


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

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

    Кеширование на уровне контейнеров


    Чтобы сделать использование ресурсов еще более рациональным, Jelastic использует механизм дедупликации памяти. Этот механизм собирает статистику об одинаковых файлах, которые чаще всего запрашиваются разными контейнерами (системные библиотеки, файлы серверов приложений и баз данных, прочие), и помещает такие файлы в кэш-память. В результате, для получения данных контейнер может обратиться напрямую в кэш вместо диска. Таким образом увеличивается производительность за счет уменьшения числа операций ввода/вывода.

    Уровни доступа


    Jelastic по своему полезен для различных груп пользователей — разработчики интернет приложений, средний и малый бизнес (которому необходим масштабируемый хостинг для стандартных приложений или SaaS), крупные компании по разработке софта, ИТ интеграторы, финансовые организации с развитыми ИТ департаментами, ну и конечно же провайдеры хостинговых услуг. Каждый тип пользователей Jelastic имеет определенный уровень доступа и определенный способ взаимодействия с платформой.

    Существует три уровня доступа к Jelastic кластеру:
    • администраторы
    • разработчики или СМБ
    • конечные пользователи

    уровни доступа

    Jelastic предоставляет две панели администрирования: Jelastic Cluster Panel (JCA) для администраторов кластера (в этом месяце планируется открыть публичный доступ к большому объему документации по этой панели), а также панель управления (Dashboard) для разработчиков. Наличие двух панелей управления с разделенными функциональными возможностями делает систему Jelastic удобным решением для Dev и Ops команд.

    Администраторы


    Администраторами платформы Jelastic являются Ops отделы компаний владеющих установленными кластерами. После установки платформа переходит в их полное распоряжение.

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

    Четыре основные задачи, которые выполняются администраторами в процессе жизненного цикла кластера Jelastic это:
    • Установка
    • Запуск
    • Управление
    • Обновление

    администраторами платформы

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

    Разработчики и СМБ


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

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

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

    разработчики и СМБ

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

    Конечные пользователи


    Конечные пользователи связаны с кластером Jelastic косвенно, путем использования приложений, развернутых разработчиками в их окружениях.

    Все входящие запросы пользователей направляются на доменное имя соответствующего приложения и обрабатываются в один из следующих способов:


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

    общий резолвер

    • через внешний IP, если он добавлен к точке входа окружения (балансировщик нагрузки, сервер приложения или база данных).

    Внейшний IP адрес рекомендуется использовать для production приложений, так как это значительно уменьшает потенциальные риски влияния одних приложений на другие. Также использование внешнего IP адреса открывает доступ к таким возможностям как удаленная отладка приложений, удаленный бекап, использование JMX, FTP, использование пользовательских SSL сертификатов, работа с вебсокетами.

    внешний IP

    Резюме


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

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

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

    CTO, Jelastic
    Руслан Синицкий
    Jelastic
    Jelastic DevOps PaaS для хостеров и ISV
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 30

      0
      >Наши ближайшие конкуренты OpenShift и CloudFoundry уже по одному разу перепроектировали свои решения внедряя слой псевдо-контейнерной виртуализации cgroup + SElinux и Warden соответственно.

      cgroups(а не cgroup) не имеют отношения к контейнерам вообще.
        +1
        косвенно имеет ru.wikipedia.org/wiki/Cgroups
        Одна из целей создания cgroups была предоставить единый интерфейс к целому спектру функциональности, начиная с контроля единичного процесса (а-ля nice) до полной виртуализации на уровне системы operating system-level virtualization (как у OpenVZ, Linux-VServer, LXC).

        Cgroups управляются различными способами:… Косвенно через другой софт, использующий cgroups, например виртуализатор Linux Containers (LXC), libvirt, systemd, и Open Grid Scheduler/Grid Engine.
          0
          cgroups — это просто счётчики/лимиты на разные ресурсы + иерархия процессов. вот упомянутый выше systemd каждый сервис сажает в отдельную cgroup.

          cgroups не имеет отношения к контейнерам просто потому что контейнеры — это просто набор флажков( CLONE_NEWNET, CLONE_NEWPID etc) для вызова clone().

          >Чтобы сделать использование ресурсов еще более рациональным, Jelastic использует механизм дедупликации памяти. Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.

          что-то я не понял. речь про дедупликацию памяти, а в итоге речь про дисковые операции. wtf?
            +1
            Спасибо. Немного изменили формулировку, надеюсь так стало понятнее. Ссылка по теме вопроса Дедупликация данных.
            Данный метод обычно используется для оптимизации использования дискового пространства
            В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.
              +1
              >В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.

              >Этот механизм собирает статистику о файлах, которые чаще всего запрашиваются контейнером, и помещает такие файлы в кэш-память.

              это обыкновенный prefetch.
                0
                ragus
                если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher), в unix системах есть аналог readahead (http://en.wikipedia.org/wiki/Readahead), и то, к системам виртуализации это не имеет никакого отношения,
                которые чаще всего запрашиваются разными контейнерами

                читайте внимательнее пожалуйста пост, здесь же имеют ввиду случай, когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины, а не одно приложение внутри контейнера
                  0
                  если я не ошибаюсь, prefetcher — исключительно виндовая фича (http://en.wikipedia.org/wiki/Prefetcher)


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

                  например, чем вам POSIX_FADV_WILLNEED не префетч?

                  читайте внимательнее пожалуйста пост, здесь же имеют ввиду случай, когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины, а не одно приложение внутри контейнера


                  вообще-то у контейнеров нет понятия «хост-машины».
                    0
                    вообще-то у контейнеров нет понятия «хост-машины».

                    есть понятие харднода, но суть не в этом

                    например, чем вам POSIX_FADV_WILLNEED не префетч?

                    сам термин «профетч» не юниксовый, вот только на этом и сделал акцент ;)
                      0
                      есть понятие харднода, но суть не в этом


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


                      что значит «на внешнем уровне»?
                      ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).

                      сам термин «профетч» не юниксовый, вот только на этом и сделал акцент ;)


                      с чего бы вдруг? наберите в гугле хотя бы «zfs prefetch».
                      думаю, если покопаться, можно найти упоминание этого слова еще во времена SunOS, когда windows еще просто не существовало.

                      но это всё лирика. в конце-концов, в системе команд IA-32 есть такая инструкция :)
                        0
                        можете пояснить вот это:

                        когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины


                        что значит «на внешнем уровне»?
                        ведь у контейнеров общее ядро(а значит, общие page cache и dentry cache, драйвера итп).


                        и что, что у них общее ядро? я ведь не о модулях адра говорил, в контейнерах можно крутить разные дистрибутивы систем, при этом каждый дистрибутив будет иметь вагон своих собственных системных либ, которые будут загружены в память как совершенно разные экземпляры, если конечно эти либы разные.
                        Вас наверное немного запутала моя фраза «один и тот же системный файл», здесь правильнее бы конечно было бы сказать «такой же точно системный файл». Хотя в случае с виртуоззой и vzfs это таки будет один и тот же файл, т.к. эти либы будут скорее всего частью остемлейта ;)
                          0
                          >и что, что у них общее ядро?

                          я где-то выше писал про page/dentry cache.

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

                          и? с таким же успехом это можно делать даже в chroot.

                          >Вас наверное немного запутала моя фраза «один и тот же системный файл»

                          нет, ни капли. меня запутала ваша фраза

                          >когда несколько контейнеров на внешнем уровне запрашивают один и тот же системный файл c хост-машины

                          вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?
                            0
                            вы не могли бы пояснить, что значит «на внешнем уровне запрашивают»?

                            ок, попробую пояснить:
                            если я нахожусь внутри контейнера и запрашиваю файл вот так:
                            CT-7777777-bash-4.1# ls -la /usr/lib/python2.6/site-packages/yum/failover.py
                            -rwxr-xr-x 1 root root 3372 Feb 22 2013 /usr/lib/python2.6/site-packages/yum/failover.py
                            я по факту запрашиваю файл /vz/private/7777777/fs/root/usr/lib/python2.6/site-packages/yum/failover.py, который физически регулярным файлом по сути не является, он есть всего лишь линком на реальный файл, если смотреть на уровне хардноды
                            [root@stage-hn1 ~]# more /vz/private/7777777/fs/root/usr/lib/python2.6/site-packages/yum/failover.py
                            ////centos/6/x86_64/yum-3.2.29-40.el6.centos.noarch/usr/lib/python2.6/site-packages/yum/failover.py
                            но вот контейнер об этом совсем «не знает», так вот, этот файл реально могут использовать десятки и сотни контейнеров, физически же он будет одним и тем же, при этом в памяти он будет подгружен тоже ровно один раз, вот-только изнутри контейнера вы никогда об этом не знаете т.к. fd в /proc вам не скажет где он используется еще
                            вот потому и на «внешнем уровне»
                              0
                              >всего лишь линком на реальный файл

                              это и есть реальный файл.
                              сделайте chroot /vz/private/7777777/fs/root
                              и у вас будет практически такой же эффект.

                              >но вот контейнер об этом совсем «не знает»

                              контейнер — это логическая сущность. для ядра процессы внутри контейнера практически ничем не отличаются от процессов вне его. все эти лимиты ubc — это предок cgroups.

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

                              а вот давайте проведем простой эксперимент.
                              соберите вот это: code.google.com/p/linux-ftools/

                              точнее, нам понадобится только fincore & fadvise.

                              берем на hn создаём файл на 1Гб:
                              dd if=/dev/urandom of=/vz/private/7777777/fs/root/1gb bs=1M count=1024

                              внутри контейнера:
                              fincore --pages=false --summarize --only-cached /1gb
                              /root/1gb bs=1M count=1024

                              внутри контейнера:
                              fincore --pages=false --summarize --only-cached /1gb
                              fadvise /1gb POSIX_FADV_DONTNEED

                              на hn:
                              fincore --pages=false --summarize --only-cached /vz/private/7777777/fs/root/1gb

                                0
                                а вот давайте проведем простой эксперимент.
                                соберите вот это: code.google.com/p/linux-ftools/

                                точнее, нам понадобится только fincore & fadvise.

                                берем на hn создаём файл на 1Гб:
                                dd if=/dev/urandom of=/vz/private/7777777/fs/root/1gb bs=1M count=1024

                                внутри контейнера:
                                fincore --pages=false --summarize --only-cached /1gb
                                fadvise /1gb POSIX_FADV_DONTNEED
                                fincore --pages=false --summarize --only-cached /1gb

                                на hn:
                                fincore --pages=false --summarize --only-cached /vz/private/7777777/fs/root/1gb
                                fadvise /vz/private/7777777/fs/root/1gb POSIX_FADV_WILLNEED

                                внутри контейнера:
                                fincore --pages=false --summarize --only-cached /1gb
                                  0
                                  сделайте chroot /vz/private/7777777/fs/root
                                  и у вас будет практически такой же эффект.


                                  тогда я вам скажу, что вы просто никогда не работали с виртуоззой, такого эффекта, увы, не будет :)
                                  [root@stage-hn1 ~]# chroot /vz/private/7777777/fs/root/ chroot: failed to run command `/bin/bash': Exec format error

                                  а вот давайте проведем простой эксперимент.

                                  вечерком обязательно попробую как доберусь домой ;)
                    +2
                    Позволю себе влезть и внести немного ясности, там используется pfcache (доставшийся Jelastic от Parallels Virtuozzo).

                    Это довольно грамотный и умный механизм, суть которой сводится к хешированию (SHA-1) определенных файлов в папках (стандартно /bin, /lib, /lib64, /opt, /sbin, /usr источник, стр 15) внутри контейнера и сохранению их хэшей в расширенных атрибутах ext4 (xattr).

                    То есть схема такая:
                    1) Ставится ОС в контейнер
                    2) User space демон pfcached забегает в контейнер и прописывает SHA-1 хэши в расширенные атрибуты ext4 для всех файлов в папках /bin, /lib, /lib64, /opt, /sbin, /usr.

                    Тут стоит обратить внимание, что силами getfattr, setfattr хэши записанные утилитой не обнаружить pfcache, так как используется особенный формат записи аттрибутов — прямо в inode. Но их можно увидеть силами debugfs (pfcache).

                    [root@fps0 ~]# debugfs /dev/ploop13314p1
                    debugfs 1.41.12 (17-May-2010)
                    debugfs:  stat /bin/bash
                    Inode: 393301   Type: regular    Mode:  0755   Flags: 0x80000
                    Generation: 2197122146    Version: 0x00000000:00000001
                    User:     0   Group:     0   Size: 903336
                    File ACL: 0    Directory ACL: 0
                    Links: 1   Blockcount: 1768
                    Fragment:  Address: 0    Number: 0    Size: 0
                     ctime: 0x52d56b41:5e497ed4 -- Tue Jan 14 20:52:17 2014
                     atime: 0x52f26e4d:b9948a40 -- Wed Feb  5 21:01:01 2014
                     mtime: 0x51e7eb48:00000000 -- Thu Jul 18 17:19:04 2013
                    crtime: 0x52d56b41:544604d4 -- Tue Jan 14 20:52:17 2014
                    Size of extra inode fields: 28
                    Extended attributes stored in inode body: 
                      pfcache = "54 e7 9f e6 15 63 f6 f5 d6 7e f6 9d f8 da bd 0f 0e 6c 5f 43 " (20)
                    EXTENTS:
                    (0-220): 89344-89564
                    


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

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

                    Также подобные «общие» файлы выносятся (тупо копируются) в отдельную файловую иерархию /vz/pfcache. За счет этого множественные загрузки данных бинарных файлов в память из разных контейнеров приводят к тому, что они занимают меньше места в оперативной памяти и кэшируются (в страничном кэше Linux) ровно один раз. Что дает очень весомый профит в экономии памяти и работе системы в целом. Причем, наибольшей экономии удается добиться именно в случае, когда все контейнеры максимально унифицированы по версиям ПО/дистрибутивам.
                      +1
                      круто! спасибо за столь детальный комментарий.
                        0
                        Вам спасибо, что начали дискуссию про уплотнение памяти pfcache, давно хотел собрать воедино мысли по ней :)
                        +1
                        спасибо за развернутый комментарий!
                        сразу видно когда человек понимает о чем пишет :)

                        меня смутил исходный комментарий

                        >В Jelastic этот механизм используется также для оптимизации операций ввода-вывода.

                        т.к. никакой оптимизаций ввода-вывода не происходит и для чтения inode всё равно будет seek по диску.
                        pfcache больше похож на uksm, только оперирующий файлами(а не страницами, как uksm).

                        Кстати, а возможно ли лимитировать в Virtuozzo контейнер по iops'ам?
                          0
                          Честно говоря, у меня почти нет опыта работы с Virtuozzo, все что я говорил из опыта работы с Parallels Cloud Server. Могу ответить про него =)

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

                          А вот с uKSM не работал, ничего сказать не могу.

                          Лимит по IOPS там есть, кроме того он теперь есть даже в OpenVZ.
                      0
                      Называть то, что есть в Virtuozzo дедупликацией абсолютно некорректно, так как ни о какой дедупликации файлов клиента речи просто не идет.

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

                      Но, потворюсь, если я загружу 100000 копий одного и того же файла, допустим, .html, то на диске так и будет хранится ровно миллион копий, не больше, не меньше :)

                      А вообще зовется оно pfcache и есть в открытом ядре OpenVZ (правда, если хотите поддержку в user space — надо ее проработать самостоятельно).
                        0
                        да, верно речь идет о дедупликации оперативной памяти
                      0
                      Я не согласен, что cgroups не имеет отношения к конейнерам. Контейнеры — это namespace + cgroups. Конечно же, namespace можно использовать отдельно, например, для создания «надежного» chroot, но какой толк в создании контейнера без лимитов по cpu/памяти и прочим ресурсам? Да никакого, это уже будут не контейнеры, а просто «некая изоляция». Вот именно по этой причине я бы не отрывал сгрупп от контейнеров, это их неотъемлемый атрибут.
                        0
                        ну так и cgoups используются отдельно от контейнеров :)

                        вообщем, «каждая селедка — рыба. но не каждая рыба — селедка».
                  0
                  Практичный вопрос, который очень важен для нас, но никто пока что из хостеров Jelastic нам так и не смог ответить:

                  Для нашего веб приложения (которое деплоится как war + DB) необходимо также уметь открывать порт для подключения к нему напрямую устройств из сети. На один открытый порт может приходится порядка 10к подключений. Такое можно организовать на Jelastic?

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

                  Также интересно было бы узнать порядок стоимости проекта внедрения jelastic у среднего хостера и у компании для внутренних нужд.
                    0
                    Для нашего веб приложения (которое деплоится как war + DB) необходимо также уметь открывать порт для подключения к нему напрямую устройств из сети. На один открытый порт может приходится порядка 10к подключений. Такое можно организовать на Jelastic?

                    Вы могли бы прислать детальное описание требований к ресурсам для вашего приложения на почту info@jelastic.com? Уверен в таком случае мы сможем дать точный ответ — можно или нет.

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

                    ссылки кое-какие битые
                    Будем признательны за конкретные примеры, если не трудно (можно на этот же адрес info@jelastic.com)

                    Также интересно было бы узнать порядок стоимости проекта внедрения jelastic у среднего хостера и у компании для внутренних нужд.
                    Стоимость в разы дешевле чем у наших конкурентов. Ждем Вашего запроса с требованиями к ресурсам, далее мы вас состыкуем с отделом продаж, который предоставит полную информацию по ценам.
                    0
                    извините, отписал не туда )
                      +2
                      Извините, конечно, что лезу в технический пост с финансовыми вопросами. Но хочется прояснить ситуацию, ибо она во многом останавливает меня (и, уверен, не только меня) на пути к тестированию и использованию Jelastic.

                      Текущая схема лицензирования Jelastic — странна (на момент 1 мая 2013).

                      Почему? Потому что Вы берете не определенную цену за использование ПО (например, в зависимости от числа аккаунтов, используемой памяти и проч), а берете процент заработанной на Jelastic прибыли. На своем веку я такую схему лицензирования в ИТ вижу первый раз :)

                      То есть, если я делаю услугу на базе своего оборудования, своей инфраструктуры продаю ее за, например, $10/месяц, то я отдаю Вам 1$ в месяц, все более-менее ок, сумма довольно мала и будет заметная лишь низкомаржинальным компаниям.

                      Но если же мы делаем серьезную, мощную услугу на дорогом оборудовании и продаем ее за $100 месяц, то мы должны отдавать Вам $20, не слишком ли это круто?

                      Кроме этого, у Вас ужасающие контракты — аж на 2 или 3 года. Даже очень крупные компании почти никогда не заключает договоры c обязательными платежами более чем на год.

                      Несколько раз перечитал страницу с предположительно (?) новой схемой ценообразования docs.jelastic.com/ru/pricing-model, но так в итоге и не нашел в чем ее суть и примерные отчисления.

                      Объясните, пожалуйста :)
                        +1
                        Спасибо за вопрос. Текущая модель называется Revenue Sharing. Она довольно распространена в хостинговой индустрии. Ее преимущество в том, что снижается риск для хостера на начальном этапе запуска продукта, так как лицензионные отчисления зависят от наличия «денег в кассе». Это очень удобно при запуске новой линейки продуктов. Далее если объем продаж увеличивается включаются механизмы скидок — больше объем продаж меньше процент revenue sharing. Наша ценовая политика довольно гибкая. Есть и годовые контракты. Суть в том что для более длительных контрактов более выгодные условия.

                        Для private cloud применяется другой подход к ценообразованию. Более привычный для enterprise сектора — лицензия за начисляется по кол-ву серверов в кластере. Кстати с 1 мая 2013 года многое изменилось по ценовой политике в лучшую сторону для партнеров/клиентов. Рекомендую обратиться в отдел продаж sales@jelastic.com, они смогут дать самую свежую информацию по ценам.
                          0
                          Ох, сделайте хотя бы на сайте визуализацию этой схемы с рычажком на количество продаж, а-то можно убить себе мозг пытаясь визуализировать ее на коленке :)

                      Only users with full accounts can post comments. Log in, please.