Стенограмма вебинара «Померяемся? Тестируем облачных провайдеров»

Вебинар состоялся 20 марта 2013 года.
Стенограмму подготовил Сергей Проуторов

Полный отчет о вебинаре находится здесь.

Начинаем наш пятый вебинар, который мы посвятим очень интересной теме – результатам тестирования облачных провайдеров. Меня зовут Владимир Мельник, мы все уже давно знакомы, и сегодня я расскажу вам о результатах тестирования облачных провайдеров, которые предоставляют так называемый облачный хостинг. Вообще, если говорить о понятиях «облачный хостинг» и «облачная инфраструктура», то стоит сразу же эти понятия разделить. Что я имею в виду? Вообще сама по себе TUCHA как продукт, как набор сервисов – это возможность для заказчика создавать инфраструктуру любой сложности: делать разные серверы в облаке, управлять этими серверами, получать на них лицензионное ПО, объединять их в виртуальные сети и так далее, то есть, получать несколько более широкий пакет услуг, чем обычно входит в понятие облачного хостинга.

Понятие облачного хостинга, как правило, несколько более суженное. Под этим понимается виртуальная машина (далее – ВМ), на которой есть заранее предустановленная операционная система (далее – ОС), которая в некоторых случаях иногда даже заточена под то, чтобы пользователь, не имеющий опыта администратора или профильного технического образования, мог на нее заливать сразу какие-то сайты и чтобы эти сайты сразу же становились видны в Инете.

К сожалению, как мы выяснили в результате нашего тестирования, далеко не все провайдеры облачного хостинга предоставляют уже по-настоящему готовую и настроенную ВМ, на которую ты сразу же можешь заливать сайт. Тем не менее, облачный хостинг – это, как правило, возможность запускать свои сайты, свои базы данных и заливать свои файлы на заранее подготовленную машину, которая как-то более-менее «заточена» под хостинговые услуги.

Так вот, у нас есть такой продукт, который называется TuchaHost – специальное коробочное решение, в которое входит заранее сконфигурированная виртуальная машина, вычислительные мощности и лицензия на ПО для управления этой ВМ. Мы используем такой популярный продукт, многие его знают, он называется ISPmanager Lite, лицензия на который входит в эту ВМ. Пользователь нажимает конопку и получает IP-адрес и пароль для того, чтобы этой ВМ управлять, чтобы через веб-интерфейс аккуратно залогиниться, создать учетные записи, прописать свои сайты и эти сайты начать заливать. Всё очень просто, всё это делается по щелчку пальцев.

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

Недавно Bing (майкрософтовский поисковик, который «тоже поисковик» – все пользуются Гуглом, но я знаю, что некоторые пользуются Bing’ом – это те люди, которые пользуются Internet Explorer’ом) проводил очень интересные исследования. Они решили померять, каким образом загрузка стартовой страницы сайта влияет на монетизацию трафика, который приходит на сайт. Грубо говоря, как это влияет на удовлетворенность пользователей. Они провели разного рода исследования, мы можем поделиться ссылкой, там много букв на английском языке, но тем не менее. Результаты их исследования показывают следующую закономерность. В том случае если время загрузки главной страницы сайта увеличивается на 2 секунды, компания в среднем теряет в своем доходе 4,3% от одного покупателя, пришедшего на сайт. То есть, на ровном месте, просто так, считайте, 1/20 часть дохода компания теряет.

Что же делать? Понятно, что можно оптимизировать код – это важно. Можно сделать стартовую страницу статической – это тоже многие делают и такие советы есть. Можно сделать многое, но что делать с остальными страницами? Предположим, у нас главная страница загрузилась быстро, но если остальные страницы будут тормозить, то посетитель может уйти немного раньше, чем мы этого хотим. Правильно? Правильно. Таким образом, мы понимаем, что скорость загрузки страницы и скорость реакции сайта вообще действительно имеют огромное значение. Потому что если мы смотрим на статистику в Google Analytics, то видим, что там есть такая страшная цифра как показатель отказов – это те люди, которые пришли, посмотрели одну страницу и ушли с сайта. Понятно, что с показателями отказов надо бороться. За счет того, что выбирать те вычислительные ресурсы, которые действительно могут помочь сайту быстро «летать» и хорошо показывать. Перейдем к показу разных красивых слайдов.

Кто у нас участвовал сегодня в «забеге»? Конечно, наш TuchaHost; MS Azure, которую «Майкрософт» делает и предлагает по всему миру, чтобы разворачивать хостинговые решения; провайдер iPROsrv; провайдер 1gb.ua – есть такой в Украине; участвовал VDS64 – тоже украинская компания; и провайдер TheHost. Чем мы меряли и что мы, собственно, меряли? Как это делалось? Было два теста, проходивших в несколько заходов – UnixBench и ApacheBench. UnixBench – это программа, которая позволяет на сервере запустить вычислительные процессы и потом проверить, за сколько времени этот сервер все эти задачи выполнит. Потом она меряет индекс в своих «условных попугаях», которые можно сравнивать только с ним самим. И второй тип тестов – ApacheBench, программа, которая наверняка есть на всех ваших серверах, это так называемый APE – часть набора сервера Apache, который эмулирует загрузку страниц с того или иного сервера и ему можно задавать количество одновременных потоков и количество итераций. ApacheBench’ем мы делали 4 теста для каждого хостера. На 50, 100, 150 и 200 тысяч. Везде включили 2 потока одновременно и тестировали их из Украины. Большинство серверов, которые мы протестировали, находятся в Украине, кроме MS Azure и TuchaHost, который, как вы знаете, работает в Голландии. При этом, что приятно, TuchaHost показал классные результаты несмотря на то, что находится немного дальше.

С помощью этой методики мы провели все наши тесты. И если кто-то хочет ознакомиться более подробно не с выводами из этих тестов, а именно с более подробными их протоколами, я даю ссылку: http://pastebin.com/u/tucha. Можете посмотреть, если будет интересно. И начали мы тестировать. Сначала мы запустили UnixBench. На сервере одного из хостеров он показал очень странный результат – там прошли не все тесты. Хостеров, на машинах которых UnixBench вообще не удалось собрать и запустить, мы вообще не включали в этот рейтинг, потому что они либо не дали рутовые права, либо они предоставили ВМ, на которой не было сконфигурировано практически ничего, поэтому они в рейтинге не участвуют. Те компании, у которых удалось получить тестовые машины действительно с нормальными рутовыми правами и получить возможность по нормальному протестить UnixBench – они есть в этой таблице. Помните, я говорил, что UnixBench меряет все в неких «условных попугаях», которые являются чисто условными единицами с точки зрения самого UnixBench. Проверив производительность с помощью UnixBench, мы получили итоги, как вы видите на слайде.

TuchaHost на одной соте, которая стоит 25 евро, и в которую входит один центральный двухгигагерцовый процессор, 2 гига «мозгов» и 125 гигов жесткого диска, показал 1038 этих «попугаев». Тестировали мы все это в разгар рабочего дня, в бизнес-время от 14 до 16 часов. MS Azure на минимальном  тарифном пакете «Малая S», который стоит почти 43 евро (тоже 1 процессор, но чуть меньше гигагерц и оперативной памяти 1,75, правда, количество оперативки не влияет на UnixBench) показал 962 «условных попугая». И другие провайдеры показали еще менее впечатляющий результат.

Потом мы запустили ApacheBench. Он показал нам три интересных вещи, по сути – две. Первое – то, сколько запросов из 100 000 не было выполнено. То есть, когда мы тестировали цифру на 100 000 итераций в два потока, какая-то часть запросов осталась невыполненной. Либо мы получили сообщение об ошибке, либо вообще таймаут. Сообщение об ошибке мы получили, как видите, почти у всех «по нулям» кроме одного из участников рейтинга, от которого мы получили 27 сообщений об ошибке. Также мы получили тайм-ауты с некоторыми участниками, как видите. Тот же 1gb.ua 27 отказов, и MS Azure и TheHost почти половину запросов не обработали.

Чтобы уточнить о методике тестирования, скажу, что мы тестировали ту сиcтему, которую пользователь получает после заказа услуги. Мы не проводили никакого дополнительного тюнинга или разного рода оптимизации. Мы взяли совершенно одинаковые продукты из коробки TuchaHost и Azure, установили на них минимум программ, которые для этого нужны, и посмотрели, а что будет? Причем, на TuchaHost вообще никаких программ, как вы понимаете, устанавливать не надо, потому что он идет уже сконфигурированный. И результаты, которые мы получили, перед вами.

Есть еще одна интересная штуковина – это время выполнения указанного процесса запросов. Объясню, что это такое. Грубо говоря, было сделано 100 тысяч запросов. И на графике, который вы сейчас видите, показано, сколько миллисекунд было потрачено в среднем на ту или иную часть запросов. Сколько процентов запросов ушло до стольки-то миллисекунд. Смотрите, 50% запросов мы видим у провайдера, который помечен толстой зеленой линией (TuchaHost), было обработано за 400 мс и менее, 66% запросов где-то за столько же, и так далее. Какая-то часть запросов обрабатывается быстро, а какая-то – чуть медленнее. И у разных провайдеров этот показатель, как видите, растет. Чем дальше, тем он растет динамичнее. И мы видим, что 95% все более-менее движутся ровно, а оставшиеся 5% запросов всегда выполняются с бόльшими задержками, чем оставшиеся 95%. Таким образом, мы видим, что некоторые провайдеры показали радикальный рост задержки после этого порога в 95%, некоторые показали минимальный рост задержки. Соответственно, если эти тесты экстраполировать – делать тест на 200, на 300 тысяч запросов, то, сами понимаете, вы увидите более радикальный рост этих кривых, но тогда они уже будут разнесены очень сильно и не будет видно всех участников.

Вообще, мы заметили еще некоторые вещи, мы не будем указывать, у кого конкретно мы их заметили, но тем не менее, мы заметили некоторые неприятные моменты, с которыми мы столкнулись. Баг номер один: нет оптимизации веб-сервера. То есть, хостер дает ВМ, на ней есть предустановленная ОС, но на ней нет настроенной среды, в которую пользователь может заливать сайт и, более того, эта среда оптимизирована под какие-то более-менее приличные нагрузки. Грубо говоря, дали коробку: «Нате, пацаны, пользуйтесь, если вы хотите, оптимизируйте себе всё сами». В принципе, это с одной стороны логично, потому что пользователь может и не захотеть, чтобы кто-то за него проводил оптимизацию, но мы считаем, что опция такая все-таки должна быть. Пользователь должен по выбору либо получить голую систему, либо систему, которая более-менее «заточена» под какие-то серьезные задачи. Так вот, у большинства системы не «заточены» и вы это видите из результатов измерения ApacheBench.

Баг номер два. Я, честно говоря, немного удивлен, но действительно некоторые хостеры могут вырубить ВМ без предупреждения. Я, конечно, понимаю, что раз это тестовая ВМ, они думают, что ничего не обязаны гарантировать клиенту, раз он бесплатно тестит. Но, тем не менее, мы считаем, что нельзя без предупреждения выключить ВМ, тем более, если она тестовая. Люди пришли посмотреть, а тут им выключают эту ВМ и включают ее только на следующий день. Выясняем: «Почему?» – «Ах, да, это были какие-то работы».

Если говорить об отзывчивости служб поддержки, то эти субъективные моменты были выражены в некоторых объективных показателях. Дают нам, например, ВМ. Мы смотрим, а на ней просто не загружается ОС. Мы говорим: «Пацаны, мы все понимаем, но вы нам дали ВМ, на ней операционка не грузится, пожалуйста, пересоздайте». В ответ мы получаем несколько неожиданное: «Мы ничего пересоздавать не будем, вы сами сломали свою ОС», и так далее. При том, что мы ее получили из коробки уже не загружающуюся. Немного странно, но ладно. Они просто выбыли из рейтинга и мы не смогли померять нашу производительность. Жаль, конечно, но, как говорится, может быть, эти компании тоже захотят принять участие в следующем «забеге» и все-таки предоставят какие-то более вменяемые ВМ, на которых мы сможет получить уже действительно хорошие результаты.

Нестабильная работа систем хостера – это приблизительно то же самое, что выключение ресурсов без предупреждения. Действительно неприятная штука, когда консолдь просто «отваливается» ни с того, ни с сего, и если бы не скрины, то там тест UnixBench’а просто сорвался бы. И так далее. Мелочи, но, как говорится, неприятно.

Неожиданные фатальные ошибки ОС – тоже. Наткнулись на одну ситуацию, когда, как уже говорилось, либо ОС не загрузилась из коробки, либо UnixBench не смог выполнить один из тестов. Понятно, что вменяемый админ, получив этот продукт, сам себе всё «заточит», сам всё снесет к чертовой матери, он сам сделает себе систему такой, чтобы она была классной, чтобы она работала. Но, с другой стороны, мы понимаем, что не всегда пользователи, заказывающие услуги хостинга, являются админами. Очень часто, наверняка об этом знаете и вы, если вы работаете в этой сфере, клиент, который заказывает услуги хостинга, это человек, у которого есть какой-нибудь бизнес, и у него, конечно, есть веб-мастера, которые сделали ему сайт или группу сайтов. Но эти веб-мастера, как правило, ничего не хотят знать об ОС, о том, какие там библиотеки и так далее. Они хотят получить платформу, на которой веб-мастер, отвечающий за код сайта, этот сайт развернет. Он хочет отвечать за код сайта. Это совершенно нормально, потому что веб-мастер писал этот код и он знает, как он работает. Или он не писал, а взял какую-нибудь готовую CMS, но,  по крайней мере, он хорошо знает эту CMS и понимает, чего от нее можно ожидать. Но веб-мастер действительно совершенно не желает разбираться с настройкой Apache, с каким-то тюнингом, он не желает разбираться с особенностями как лучше в SQL-е сделать оптимизацию запросов. То есть, веб-мастеру это все не надо. Тем более – заказчику. Поэтому, говоря по правде, давать систему, которая не готова к тому, чтобы на нее можно было заливать сайт и ожидать от него стабильной работы, нам кажется, не совсем правильно.

Тем не менее, как бы там ни казалось, что мы имеем по TuchaHost’у? Какие преимущества своего же продукта мы тут же выявили? Во-первых, мы имеем по-настоящему мощные серверы и их мощность – не просто слова, это могут подтвердить абсолютно все наши клиенты, которые до того «жили» на каких-то других мощностях и платформах, и когда они приехали к нам, они действительно оценили, что ЭТО действительно работает быстрее, стабильнее и надежнее, и ЭТО выгодно.

И второе преимущество – это ПО, которое было уже заранее оптимизировано, подготовлено, «заточено», и люди просто заливают свои сайты и больше им ничего не надо делать. Сайты быстро работают, «стреляют» и пользователи довольны. Таким образом, кроме максимума возможностей, конечно же, хочется упомянуть и такое преимущество как масштабируемость, потому что если говорить, что эта услуга облачная, то мы понимаем, что можно в любой момент менять конфигурацию и набор возможностей облачной инфраструктуры. Соответственно, мы понимаем, что мы можем варьировать мощность наших серверов от 1 до 8 процессоров, от 2 до 16 гигабайт оперативной памяти и даже от 125 гигабайт до 1 терабайта дискового пространства. На этом «градуснике» мы нарисовали этот момент где-то здесь. На самом деле TuchaHost этим не ограничивается. Можно набирать несколько серверов, объединять их в веб-кластеры и получать гораздо больше мощностей. Но для этого существует уже более подготовленный продукт – не TuchaHost, а TUCHA как таковая. То есть, именно не услуга облачного хостинга, а услуга облачной инфраструктуры. Помните, о чем я говорил в самом начале? Это возможность создавать целый ряд серверов, который будет объединен не только внутренней локальной сетью, но и какими-то параметрами управления, и эти серверы можно будет использовать как один большой мощный кластер.

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

Также хочется подчеркнуть еще одну вещь. Есть очень много облачных провайдеров, о которых говорят, что они намного дешевле других. В этом случае иногда бывает полезно задать провайдеру ряд вопросов, которые позволяют прояснить, почему именно услуги этих провайдеров являются совсем дешевыми и в чем, собственно, состоит отличие провайдера А от провайдера Б. Нелишним бывает задать провайдеру вопрос, в каком ЦОД располагается его оборудование. Как вы знаете, некоторые провайдеры размещают свои серверы в голландском дата-центре, который называется EvoSwitch и в котором уровень защиты TIER 3+. А некоторые – либо просто у себя где-то в офисе, в углу (я, конечно, не беру такие случаи во внимание), либо они размещают это в украинских дата-центрах уровня TIER 1 или TIER 2. Как говорится, сэкономили, дали хорошую цену, ура, все хорошо. Но стабильность работы дата-центра TIER 1 или TIER 2, мягко говоря, отличается на десятые доли процента, а то и на проценты от работы дата-центра уровня TIER 3.

Можно задать провайдеру вопрос, какое именно оборудование он использует. Дело в том, что оборудование, которое можно использовать, это либо брендовые серверы, типа Hewlett, Dell или IBM, как у некоторых провайдеров, либо просто «самосбор» – хороший, качественный, но который  иногда может предложить какой-нибудь интересный сюрприз. Конечно, мы с вами знаем, что если провайдер не пожлобился и использует кластерное решение для своего облака, то он гоняет ВМ не на одном сервере, а на их группе, и ВМ могут мигрировать между этими серверами. И не лишним бывает задать вопрос, используется ли такое решение этим провайдером? Потому что в том случае если ВМ жестко привязана к гипервизору, то любые плановые работы либо авария на гипервизоре может, мягко говоря, негативно повлиять на работу веб-сайтов виртуальных машин.

TuchaHost при этом, кстати, позволяет использовать оба варианта – с привязкой к гипервизору, более дешевый, и вариант размещения TuchaHost на кластере, несколько более дорогой, но более эффективный как с точки зрения быстродействия, так и стабильности. В первом случае гарантируется SLA 99%, а во втором – 99,9%.

Также иногда бывает полезно задать провайдеру вопрос о том, как происходит изоляция данных клиента, то есть, какая именно среда виртуализации и какие решения используются, и насколько они надежны. Насколько велика вероятность того, что клиент, который «поселится» в этой среде, не получит данные других клиентов, то есть, «проломив» свою ВМ, не залезет в ВМ соседей. Это важный вопрос и, говоря по правде, пользователи его редко задают, потому что не всегда представляют себе, что такое вообще возможно. А задавать этот вопрос стоит.

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

Еще интересно бывает спросить провайдера, содействует ли он клиенту во время его миграции. Предположим, что я – заказчик, у меня есть группа сайтов и я хочу переехать в облако к какому-нибудь провайдеру. Мне провайдер дает ВМ и говорит: «На, всё, работай, хорошо, молодец». А я, может быть, хочу, чтобы мне провайдер помог мои сайты перенести. В случае если мы говорим о провайдере А, то провайдеры не всегда содействуют этому. Если о провайдере Б, то он содействует этому всегда.

Бывает полезно задавать вопрос, каким образом закрепляются отношения между клиентами и провайдером. Вообще, есть ли договор. Или вместо него клиент просто ставит галочку «я прочитал и согласен», а потом не имеет никаких юридических документов, которые могли бы сыграть хоть какую-то роль в его судьбе. Это важно. Более того, не все провайдеры имеют юридическое лицо в Украине. Как вы знаете, взаимоотношения с провайдером, у которого есть юридическое лицо в Украине и который является еще и плательщиком НДС, более выгодно, во-первых, с точки зрения налогового учета, во-вторых, более надежно, как уже говорилось, с точки зрения юридической подстраховки. Есть договор – можно говорить о каких-то гарантиях. Нет договора – о чем говорить? И это важный вопрос, которым заказчики не всегда задаются, до поры до времени.

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

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

Вопрос: Почему вы сравнили именно эти компании? Неужели на рынке так мало альтернатив?

Ответ: Знаете, альтернатив полно, но дело в том, что мы просто не успели завершить тестирование некоторых компаний. Кстати, на нашем аккаунте в http://pastebin.com/u/tucha вы найдете результаты тестирования еще парочки облачных провайдеров, которые мы не успели вписать в этот рейтинг. Там есть еще, если не ошибаюсь, такой провайдер как HostPro, мы по нему провели тестирование по ApacheBench и результаты нам тоже очень понравились, а по UnixBench мы не успели провести тестирование, но, насколько мы помним, там должны быть сходные цифры. Потому что они хвастались, что у них вроде бы как тоже все хорошо, мы надеемся, что так оно всё и есть.

Все же ApacheBench показал, что наши результаты несколько лучше, вы можете пройти по ссылке в http://pastebin.com/u/tucha и проверить. Тестирование некоторых провайдеров мы завершить не успели к сегодняшнему дню, а тесты других просто не удалось провести из-за технических неполадок, которые у них возникали. Либо не дается полный административный доступ для того, чтобы собрать нужные пакеты, установить, собрать UnixBench и провести тестирование, или просто возникали какие-то технические проблемы, поэтому некоторые даже не вошли в рейтинг и мы не стали их упоминать. Например, провайдер Иванов не вошел в рейтинг, потому что его ВМ умерла на старте. Такие тоже были. А так – да, альтернативы полно.

Вопрос: Не боитесь, что конкуренты проведут свои тесты и получат противоположные результаты?

Ответ: Мы вообще мало чего боимся, особенно – тестов. У нас есть возможность взять тестовую услугу, провести на ней любые замеры и – пожалуйста, сравнить со своими. Если получатся противоположные рузультаты, мы бы с удовольствием об этом узнали, если честно. Почему? Потому что было бы интересно сравнить – а вдруг нам еще есть что оптимизировать. Говоря по правде, мы точно знаем, что оптимизировать систему можно еще больше, но сейчас те результаты, которые мы получили, в принципе, нас удовлетворили. Если кто-то их перебьет – ОК, тогда мы потратим пару часов времени, покажем новые результаты и будем опять сидеть довольные.

Вопрос: Можно ли сразу давать тестовую ссылку https://tucha.ua/demo/ потенциальным клиентам в электронном письме?

Ответ: Да. У нас сейчас на сайте, кстати, мы уже сделали такую формочку, в которую можно «забить» свои реквизиты и получить в ответ реквизиты тестового доступа. По этой ссылке https://tucha.ua/demo/ можно заказывать тестовую инфраструктуру и ее всячески обкатывать. Поэтому можно сразу давать эту ссылку в электронном письме.

Вопрос: Вы говорили о службе поддержки. Есть ли расширенная поддержка с вашей стороны если мы арендуем как веб-студия?

Ответ: Да, конечно. Есть так называемый пакет TuchaExpert, он стоит совсем недорого, если не ошибаюсь, всего 30 евро в месяц, и это пакет, который пристегивается к TuchaHost’у и позволяет получить расширенную поддержку на уровне ОС, библиотек, а также интерпретатора и его обвязки. То есть, по умолчанию хостер отвечает за работу ВМ как таковой, но не лезет в ОС, а в случае если хостер должен отвечать и за ОС, то клиент может заказать TuchaExpert, который стоит как минимум 30 евро. Вычисляется цена таким образом: стоимость составляет 50% от стоимости самого сервера, но не менее 30 евро.  Желательно уточнить с помощью калькулятора на нашем сайте, поскольку я мог что-то забыть.

Вопрос: Насчет сравнения. Как вы выбирали конфигурации? Явно же у всех есть собственные линейки конфигурации по некоторой логике и сопоставить их может быть проблематично.

Ответ: Ну да, вообще мы выбирали таким образом. Либо чтобы мы попадали в пределы 25 евро, либо – в одно ядро и пару гигабайт оперативной памяти. Усредняя по этим двум осям, мы выбирали конфигурации по тестированию. По сути, это было соревнование минимальных конфигураций, «забег детей». Если бы мы тестировали более крупные конфигурации, я уверен, что разрыв был бы еще более существенным. Но тесты длились бы чуть дольше, а мы хотели запустить этот вебинар уже сегодня, поэтому тесты мы провели очень быстро. Поскольку мы не хотели тестировать ночью – не от лени, а чтобы тестировать бизнес-время, нам пришлось немного поспешить. Да, цена сравнима, если не принимать во внимание какой-нибудь Azure, который стоит 42 евро. А так – цена сравнима: меньше 100 евро в месяц у всех участников, даже меньше 50-ти.

Вопрос: Какие ОС есть у вас в арсенале? Если служба поддержки платная, то могут ли быть развернуты какие-то экзотические шаблоны?

Ответ: В TuchaHost мы рекомендуем использовать наши шаблоны. Это шаблоны, построенные на базе Linux CentOS и Linux Ubuntu. Это те системы, которые были нами «вылизаны», оптимизированы и так далее. В принципе, для того, чтобы использовать другую систему, например, Винду, надо брать не TuchaHost, а облачную инфраструктуру TUCHA. Потому что для Винды у нас есть отдельные решения и отдельные продукты. Хочу подчеркнуть, что в TuchaHost на данный момент есть два шаблона: Linux CentOS и Linux Ubuntu. Если мы увидим, что со стороны потенциальных заказчиков есть интерес к другим системам, мы «заточим» и другие системы под это дело. По сути, Ubuntu у нас появилась потому, что один из наших клиентов сказал: «Я хочу перейти на вашу TuchaHost». Он арендовал у нас физическое «железо», но оговорил: «Я перейду, только если у вас будет шаблон под Ubuntu». Хорошо, посидели пару дней, сделали этот шаблон и теперь он у нас есть. Если клиент скажет: «Я хочу шаблон под FreeBSD», мы скажем: «Есть». Более того, если честно, мы уже делали шаблон под FreeBSD для одного экзотического случая, но он, правда, делался не для TuchaHost, а для полноценной TUCHA. По поводу шаблонов наша политика такова: чем будет их больше, тем лучше и для клиента, и для нас. Соответственно, мы будем наращивать их с большим удовольствием.

Вопрос: Тест тестом, а есть ли возможность посмотреть изнутри, как это работает? В гости не боитесь пригласить?

Ответ: Конечно не боимся, мы находимся на 24-м этаже, так что если не боитесь высоты, то пожалуйста, приходите.

Вопрос:  Если арендуется сервер, то есть ли какая-то встроенная возможность мониторить его состояние, чтобы не «вязать» левый сервис?

Ответ: Да, конечно. У нас есть система, она называется Nagios и позволяет мониторить не только состояние ВМ, но и состояние служб на ней. Мы можем настроить для клиента мониторинг, чтобы проверять не только насколько эта ВМ отвечает на «пинги», но и загружается ли веб-сервер, главная страница сайта, присутствует ли на главной какое-то словосочетание, потому что если, например, веб-сервер загружается и мы хотим понять, то ли загружается, что должно, мы можем закрепить мониторинг за какой-то последовательностью символов, и если эта последовательность символов не загрузилась, то система мониторинга поднимет «хай» и поставит в известность и нас, и клиента. Стоит эта дополнительная услуга, если не ошибаюсь, 10 евро в месяц. Она востребована, некоторые компании ее заказывают для того, чтобы быть в курсе того, что происходит, чтобы вовремя отреагировать на какие-либо вызовы со стороны своего сервера. Облачная структура может работать идеально, но даже из-за какой-нибудь ошибки в коде самого сайта он может в какой-то момент перестать работать, или дисковая система переполнится. Заказчик хочет знать об это заранее. И такая система мониторинга в этом плане очень помогает.

Вопрос: Расскажите про свой SLA. Если берешь большие ресурсы, то хотелось бы знать больше инфы про него.

Ответ: Есть по сути несколько SLA – для TuchaHost и для TUCHA, которая является универсальным конструктором. SLA для TuchaHost подразумевает, что, в зависимости от того, берется TuchaHost кластерная или некластерная, он подразумевает разные показатели доступности. В первом случае показатель доступности 99,0, во втором – 99,9. Там есть еще куча разных параметров типа скорости ответа службы технической поддержки – столько то часов и т.п. Я их все сейчас не назову. Напишите свой адрес и мы вышлем вам, а еще лучше – в ближайшее время опубликуем стандартный SLA на сайте. Причем для TuchaHost SLA делится на 2 категории – TuchaHost кластерная и некластерная. Мне подсказывают, что эта информация выложена, но на нее есть ссылка из договора, но нет ссылки на сайте. Мы сделаем эту ссылку на сайте в ближайшее время для того, чтобы все могли видеть SLA.

Вопрос: Вы даете полный рут? Не так, как MiroHOST, когда рут остается у провайдера?

Ответ: Когда мы тестировали MiroHOST, мы не получили полный административный доступ к ВМ. Да, конечно, мы даем полный рутовый доступ и пользователь может устанавливать там любые программы. По сути, ключи от квартиры переданы и, как говорится, делай в этой квартире, что хочешь. Единственное, если пользователь выбирает пакет расширенной технической поддержки – когда за работу ОС отвечаем мы, то в этом случае рут мы предпочтем оставить за собой, потому что мы будем отвечать за все, что происходит на уровне операционной ситстемы. По умолчанию полный рутовый доступ дается всем клиентам без исключения, но если за операционку отвечаем мы, то (если мы не согласуем это отдельно) все-таки рут останется у нас, потому что, сами понимаете, мы будем за это потом отвечать, и чтобы для нас не было сюрпризом, почему перестал работать какой-то компонент системы.

Спасибо всем и до новых встреч, 27 числа буду рад видеть всех на вебинаре.