ihor.ru: VDS с SSD от 250 р, Сервера, Хостинг в Москве. Отзывы обсуждения предложения

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

Касательно Вашей ситуации:

Никаких аномалий на сервере, на котором находится Ваш VDS, мы не обнаружили. Средняя, штатная нагрузка.

При тестах, на пустом сервере используемой нами конфигурации, скорость линейной записи, достигает 231 Мб/с. По этому, показатель в 53 Мб/с является, весьма не плохим для тарифа Cuprum (тем более, если Вы производили замер на рабочем сервере, без остановки всех служб на нем, а соответственно, они тоже кушали диски в этот момент). На некоторых нодах, можно получить 120-160 Мб/с (несколько страниц назад, здесь приводили примеры). Если хотите, можем еще раз, Вас отмигрировать на менее нагруженную ноду. Но опять же, без какой либо гарантии, что скорость будет всегда одинакова.

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

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

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

Итог: сейчас, имеем, то что имеем, но на месте не стоим. Гарантий, что скорость диска всегда будет неизменной, мы никогда не давали. По этому предлагали тестовый период. Отдельно стоящих тестовых серверов у нас никогда не было, все размещалось вперемешку. Если клиента не устраивает текущая скорость работы, всегда готовы отмигрировать его на наименее нагруженный сервер. Естественно, не в наших интересах, когда производительность сервера стремится к нулю и мы постоянно работаем над оптимизацией. Но по любому, у серверов есть свои физические пределы по скорости, выше которых, мы предоставить не можем. И если, для Ваших задач не хватает производительности наших серверов, то тут, могу только посоветовать взять выделенный сервер, тогда все доступные ресурсы сервера будут в Вашем распоряжении. Или же, посмотреть в сторону не лоукост сегмента услуг. У нас, пока, такого предложения нет. Из имеющихся, здесь на серчах предложений, и чтобы в России, могу посоветовать обратиться к sladkydze, но если не ошибаюсь, то у него минимальный ценник 1к рублей. Но за то, получите в пользование СХД уровня Enterprise, где скорость дисковой подсистемы будет существенно выше, чем в нашем standalone-решении с двумя дисками в RAID1.

---------- Добавлено 07.05.2015 в 23:30 ----------

Напишите в тех. поддержку, с ссылкой на этот пост, думаю, найдем для Вас решение с доступом по SSH к хостинг-серверу.

Ivan Lungov, отлично буду обращаться.

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

Иван, спасибо за развернутый ответ. По второй проблеме (iowait) вопрос, как я понял, решается мигрированием. Следовательно, каждый раз при необходимости буду запрашивать мигрирование в поддержке.

Что же касается первой проблемы, когда диск был переведён в режим read-only вы, видимо, недостаточно хорошо разобрались в сути ситуации, следовательно, я настаиваю на более детальном рассмотрении проблемы. Последствия данной ситуации меня не устраивают, поэтому я не оставлю эту проблему без пристального внимания в случае игнорирования моего обоснованного беспокойства.

Согласен.

Потому как заявления "веб-журналиста" вроде:

по меньше мере поражают и удивляют.

Я уже писал, могу повторить снова:

1. Почему диск внутри Вашего VDS перешел в read-only, мы не знаем, для этого нам нужен доступ к Вашему VDS, а у нас его нет.

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

3. Даже если на гипервизоре закончился бы диск, это никак не влияет на работу VDS, поскольку, диск для VDS является блочным и создается сразу того размера, который указан в тарифе. Это примерно также, как создание дисков C: D: E:... на Вашем компьютере. Когда Вы разбили жесткий диск на разделы, он считается заполненным на 100%. Но это не значит, что внутри логических дисков тоже нет места.

4. По сути, когда предоставляется услуга VDS, зона ответственности хостера заканчивается на запуске виртуальной машины. Если эмулятор BIOS стартанул успешно, значит VDS, с точки зрения гипервизора работает. Какая операционная система будет грузится и как она будет работать, это уже зона ответственности клиента. Например, если Вы выполните внутри Вашего VDS команду "rm -rf /*", то почему мы должны отвечать за потерю данных? Вы покупаете комп в магазине, магазин предоставляет гарантию, что железо будет работать. Но ни один магазин не даст Вам гарантию, на возможные проблемы с софтом, который Вы поставите на этот комп. VDS, является тем же самым виртуальным компом. Хостер, гарантирует, что виртуальное "железо" будет работать и виртуальная сетевая карта будет подключена к Интернету.

Если Ваша ОС перевела диск в режим read-only, то мы то тут причем? Вот если бы она написала бы что диска нет вообще, тогда это наша проблема. А диск, в режим read-only, может перевести любой сисадмин в любое время, если у него есть доступ к системе.

5. Безусловно, мы хотим, чтобы у наших клиентов все работало без сбоев, чтобы сайты крутились, странички открывались и т.п. По этому у нас есть тех. поддержка, которая готова прийти на помощь в случае возникновения внештатных ситуаций. И внутренняя проблема Вашего VDS, была решена нашими специалистами в максимально сжатые сроки. Файловую систему починили, сервер запустили.

---------- Добавлено 08.05.2015 в 21:26 ----------

В Вашем случае, как ТП и написало, возник дефицит ОЗУ на ноде. Мы уже несколько раз замечали такую ситуацию, когда VMmanager по какой то, только ему понятной внутренней логике, пытается уместить на сервер больше VDS, чем это возможно, хотя, по всем параметрам, не должен был этого делать. В начале, такие ситуации были не редки. По этому мы стали комплектовать новые серверы дополнительным объемом ОЗУ, сохраняя при этом ограничение на количество VDS размещаемых на сервере. Сейчас, еще осталось некоторое количество серверов с меньшим объемом памяти. Поскольку эти серверы водились в строй первыми, там уже состоявшийся контингент пользователей и какие либо движения происходят редко, но иногда бывают. На свежих нодах, такой проблемы не возникало.

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

Прошу прощения, что влажу, но установка лимита использований в биллинге на одну ноду должна решить проблему. ;)

В биллинге ставится целиком на кластер, а не на конкретную ноду.

Ограничение на ноду настраивается в VMmanager, иногда ловим такую ситуацию, например стоит ограничение в 30 вдс, но в какой то момент и каким то боком туда пролезает 31-я.

В VManager много багов, и скорее всего, это один из них. В новом кластере, будем использовать более свежую версию, возможно, ИСПшники уже исправили этот баг.

Внятного ответа по проблеме рид-онли не получил. Написал sladkydze.

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

Если можете смириться - забейте, не можете - меняйте хостинг, и не мучайте ни себя, ни их. Видно же, что это не DO и не Linode. Примите как данность, что вероятность возникновения проблем у этого хостинга пока ещё весьма высока, оцените стоимость рисков, и в зависимости от этого или экономьте на хостинге, или переезжайте.