Как стать автором
Обновить

Комментарии 29

Что-то увидел заголовок, и подумалось — а почему до сих пор нет сервиса, позволяющего продавать свои собственные мощности, по типу того же аукциона. Или может есть, никто не подскажет?
У Амазона есть нечто подобное: если есть простаивающие ресурсы, то провайдер выставляет их на аукцион, в котором пользователи
сами назначают цену одного часа аренды ресурсов. Победитель получает незадействованные ресурсы по его цене. Однако как только на ресурсы снова появится спрос или ставка будет перебита, то эти ресурсы больше не ваши. Как-то так.
не совсем то имел в виду.
Вот у меня есть выделенный сервер определенной мощности с определенными показателями uptime и каналом связи. Могу ли через какой-то сервис зареселлить его конечным клиентам, заплатив за это сервису определенный процент?
А как вы будете гарантировать SLA?
Отказоустойчивость засчет балансировок. Понятно, что SLA будет ниже, чем на любом другом хостинге. Но и стоить это будет дешевле.
На самом деле, я не собираюсь разрабатывать подобный сервис, у меня недостаточно знаний для этого. Просто интересуюсь, реализована ли подобная идея.
Если речь идет о компенсации, то за нарушение SLA мы начисляем бесплатное время пользования сервисом.
Фиксация нарушений SLA будет проходить на основании нашей системы мониторинга и обращений клиента на support@cloudlite.ru.
Что мне особенно «нравится» в SLA, так это пункты про то что исполнительно может выключать ресурсы клиента для проведения собственных работ и эти простои не входят в общий % Uptime по SLA.

Например у вас пункт 4.1.2. вы можете выключить серверы на обновления/тестирования на любое, ничем не ограниченное время без предварительных предупреждений клиента.
Не совсем так: в пункте 4.1.2. речь идет об обновлениях и патчах, имеющих критическое значение для работоспособности, производительности, безопасности ОС.
Уведомление рассылается в обязательном порядке всем клиентам (на email, указанный при регистрации) непосредственно перед работам с указанием примерного времени работ. Об этом также написано в этом пункте.
Да и я о том же. Предположим находится баг, аналогичный недавней уязвимости bash, только в vmware. Уязвимость несомненно критичная. Исполнитель решает что это критично, рассылает предупреждения и одновременно выключает оборудование для установки патчей/исправления настроек. Потом тестирует что всё работает хорошо во всех возможных вариантах (тесты обычно занимают уйму времени). А в это время у клиентов например разгар торговли или какое-то важное выступление/презентация и всё накрывается.

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

Что интересно — такой пункт я видел не только в dataliteво всех или почти всех SLA — ограничения на собственные работы очеь и очень мягкие и не входят в гарантируемый % доступности.

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

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

Business critical размещать без off-site горячего резерва?
Лично я конечно верю в SLA, в отечественных провайдеров, и так далее, но не настолько, что бы держать все яйца в одной корзине.
Только репликация, только самостоятельное внутреннее тестирование на тему «что будет, если наш основной ЦОД окажется недоступным»
Если строить такую инфраструктуру самостоятельно, то пользоваться отказоустойчивыми решениями провайдеров вообще смысла нет — только переплачивать лишний раз и при этом всё равно оставлять на себе задачи и расходы по дублированию системы.

К тому же в большинстве случаев провайдер может сделать лучше, т.к. он на этом специализиуется. У себя имеет смысл хранить обычные резервные копии на случай глобальных проблем провайдера, но не дублировать всё в реальном времени еще раз.
Почему строить инфраструктуру самостоятельно? В данном конкретном примере — ЦОД на базе Vmware вполне реально сделать дублирование в amazon web services или же на какой-то другой сферический Vmware-based ЦОД. Вся эта магия происходит в автоматическом режиме, для вас остается задача тестирования, как все будет работать в случае сбоев в том или ином месте;
А насчет дублирования в реальном времени — это вопрос насколько, собственно, Business и насколько critical у вас приложения и сервисы.
Опять-таки есть ряд нюансов, из-за которых картина выглядит не столь пугающей, как Вы обрисовали ))

1. Если говорить о гипервизорах VMware, то все работы по установке обновлений/патчей можно производить последовательно, на каждом отдельном сервере, передвигая ВМ на другие сервера с помощью vMotion (благо для таких операций есть всегда резервные сервера). Если все-таки потребуется перезапуск ВМ для каких-то обновлений, то да, в этом случае у пользователя будет небольшой перерыв в работе его сервиса (например, интернет-магазина).

2. Тестирование после установки обновления/патча не занимает много времени, и уж тем более не выльется в ситуацию «всё облако месяц лежать будет» :)
В целом Ваши опасения понятны, радикальное решение этой проблем, как отметил nickolazz, это использование облака с географически распределенным кластером на нескольких площадках. Это собственно предлагается в рамках CloudLine.
Я понимаю что можно производить всё по-очереди и мигрировать клиентов на серверы с которыми работ не проводятся — сам так делаю.

Однако пункт наверное включен не просто так и по договору позволяет при серьезных внутренних проблемах сослаться на этот пункт (выполнялись критически важные работы) и по факту в этом случае ни за что не отвечать.

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

Я понимаю что на практике никто лишний раз специально простоев клиентам устраивать не будет — это не выгодно, сейчас я говорю про юридическую сторону вопроса. Имея такой пункт в соглашении SLA он очень сильно теряет в гарантиях. Например возможны ситуации:
1. Исполнитель проводит установку критических обновлений на маршрутизаторы (при этом маршрутизаторы сошли с ума и несколько часов пришлось их восстанавливать и учить заново друг с другом работать), ответственности 0 — по пункту 4.1.2
2. Исполнитель устанавливает критические обновления на систему хранения данных, без которых есть шанс потерять все данные (редко проявляющийся баг прошивки). Что-то пошло не так и хранилище ложится. Тут конечно есть вендорная поддержка — звонок производителю хранилища, начинаются срочные решения. Сколько-то часов/дней они занимают (например если метаданные были испорчены и хранилище надо собирать по кусочкам в ручном/полуручном режиме). Ответственность исполнителя 0 — по пункту 4.1.2.

И т.п.

Кстати, SLA на геокластер где можно почитать?
Небольшое замечание: VMWare HA — это не автоматическая миграция в случае сбоя, а перезапуск виртуальной машине с сломаного сервера на любом рабочем узле кластера.
То есть важно, что виртуальная машина обяательно уйдет в даун вместе с дохлым сервером. Потом кластер увидит сбойный узел, потом выберет свободный узел, и только потом — запустит ВМ.
Большое спасибо! Поправили :)
А можно поинтересоваться вашими железками — судя по 4хCPU в комбинации с intel x520 10GbE предполагаю, что у вас сервера не HP, не Dell и не IBM, может быть это что-то от супермикро?
Если эта информация не является «коммерческой тайной», разумеется
Используем сервера Huawei FusionServer RH5885 V3, процессоры E7-4830 v2.
Спасибо, интересно, с Huawei дел пока не имел, руками не трогал
:-)
А это не «Титаник» случайно на последней картинке? :-)
Нет, мы проверяли :)
Гугл вроде говорит, что это SS El Oriente.
Он отходил аж две войны :)
Заценим, покрутим ) Постараюсь еще отчет написать в виде поста в бложеке. Если не забуду отпишу вам на почту потом.
Пишите, будем признательны за обратную связь :)
Может у меня руки не из того места растут, но я так и не разобрался где указать/получить root-пароль для созданного инстанса с CentOS. И еще инсанс почему то сразу с иксами развернулся.
Возможно, вам поможет вот эта инструкция. Если все-таки не получится самостоятельно решить вопрос, пишите на support@cloudlite.ru.
Ну теперь то все понятно. То ли я прошлой ночью не туда нажал, то ли что-то еще. В наличии был только образ с CentOS где в description есть только логин. У части образов пароли дефолтные действительно в описании.
Отлично, что все получилось). Панель, конечно, не для новичков, зато дает существенно больше возможностей в настройке.
Ну я как бы не новичок, но это пока замая запутанная панель которую приходилось видеть) Даже в Amazon на первый взгляд все понятнее) Вам бы как то может сразу ссылки на FAQ при реге скидывать. Сильно помогает)
Спасибо, добавим)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий