Pull to refresh

Comments 18

А как у Вас обстоят дела с другими SQL решениями, Например Postgres
На данный момент платформа Jelastic поддерживает следующие SQL серверы: MySQL 5.5, MariaDB 5.5 и 10.0, PostgreSQL 8.2 и 9.2.
У Jelastic нет SSH, что убивает всяческое желание использовать на практике. Кроме того у Drupal например есть Drush, кто с ним работает, того не заманишь использовать графический интерфейс.
Скоро будет SSH доступ к каждому компоненту… А пока Вы можете подключить Public IP и попроcить хостинг провайдера включить Вам SSH доступ. Или просто купить Elastic VDS и использовать там SSH. Такой вариант решает вопрос?
VDS как вариант лишь для тех у кого руки на месте, и тянет за собой дополнительные затраты для клиента по настройке сервера.
Затраты будут такие же как и на любом другом стандартном хостинге. Но в этот же момент вы получите преимущество вертикального масштабирования и будете платить только за реально используемые ресурсы. Плюс можно использовать плюшеки по клонированию и остановке окружения.

Давайте начнем с того — а зачем Вам нужен SSH доступ? Пример с Drupal понятен. Еще какие-то конкретные нужды?
Конечно это разные стратегии, и продукты для этого создаются разные под свою нишу клиентов, где они не пересекаются, тема для описания своей конкурентоспособности хостера на рынке услуг.

SSH для меня решающий фактор, эконимит много времени.
Такой вопрос, а как у «Jelastic.Cloud» обстоят дела с uptime? Т.е. вопрос в следующем: есть проект, у которого не должно быть простоя вовсе, т.е. uptime желательно 100%, на облако хотелось бы вынести main сервер (mysql master, nginx, php, apache), как я понял для этого понадобится брать «Elastic VDS», что бы можно было настроить nginx, mysql.
+ если брать «Elastic VDS» будет ли динамически выделятся ресурсы по мере их потребления?

Спасибо
Спасибо за хороший вопрос.
uptime желательно 100%

Uptime зависит от SLA конкретного хостинг провайдера, в данном случае от Infobox.

на облако хотелось бы вынести main сервер (mysql master, nginx, php, apache)

Все перечисленные стеки поддерживаются как стандартные шаблоны, т.е. не нужно покупать VDS
Ссылки по теме
jelastic.com/ru/docs/nginx
jelastic.com/ru/docs/http-load-balancing
jelastic.com/ru/docs/nginx-caching
jelastic.com/ru/docs/apache
jelastic.com/ru/docs/database-master-slave-replication

Есть также shared resolver jelastic.com/ru/docs/shared-resolver
но для Вашего случая рекомендую использовать внешний IP jelastic.com/ru/docs/public-ipv4

+ если брать «Elastic VDS» будет ли динамически выделятся ресурсы по мере их потребления?

Но в любом случае если вы возьмете Elastic VDS — ресурсы будут выделяться динамически и не нужно платить за то, что не используется
Если говорить официально, то SLA предполагает доступность сервисов 99,99%, что является очень высоким показателем.
По факту на уровне дата-центра за 4 года существования его аптайм составил 100%.
Jelastic в продакшне еще всего месяц судить рано, но пока и его доступность составила 100% даже во время беты.
Как Вы понимаете, 100% аптайм гарантировать не может никто, но в целом Jelastic как раз подходит для отказоустойчивых решений. Настроить MySQL как master для репликации с другими серверами можно и без VDS. Более того, ведомые ноды также можно разместить на Jelastic, на сайте вендора есть инструкция. Конфигурация Nginx также доступна для изменения.

Для Elastic VDS также работает масштабирование ресурсов, вот наша статья об этом.
Еще такой вопрос возник: какое кол-во IOPS можно получить с дисковой подсистемы?
На время беты ресурс IOPS Limit установлен на 100 операций в секунду, в индивидуальном порядке можем увеличить этот параметр для Вашего аккаунта по заявке в техническую поддержку.
А что на случай ддоса предусмотрено?
скорее всего что Ваше окружение вынесут на внешний IP jelastic.com/ru/docs/public-ipv4 и будут уже дальше думать чем и как Вам помочь
Сама платформа не включает средства для борьбы с ДДОСом. С атаками мы боремся на уровне нашего дата-центра. Как правило, успешно и оперативно справляемся.
При сложных случаях рекомендуем Клиентам использование внешнего айпи и пропуск трафика через специализированные сервисы.
Без иронии, это движение в правильную сторону. Но, а) тема сисек не раскрыта, и б) ох уж эти унылые «особенности» джеластика для LAMP-стэка.

Во-первых, использовать неебическую хренотень, чтобы ручками редактировать innodb_flush_method — это за гранью добра и зла. Могу поспорить, что даже внутри команды Юми никто толком не знает, чего эта штука делает.

Во-вторых, Jelastic это инструмент для менеджмента окружений. Гораздо правильнее было бы рассмотреть кейс, когда с помощью Jelastic реализуется процесс непрерывной интеграции сайта на UMI.CMS через dev-stage-prod-окружения. Как вносятся изменения в конфигурацию, как они мигрируют по этому процессу от дева к проду. Как осуществляется деплой проекта, откат, работа с feature-branches, их тестирование и вывод в продакшен.

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

А за идею для будущего поста спасибо! Приглашаем в соавторы-соиспытатели.
Sign up to leave a comment.