Комментарии 47
Как конечного потребителя, меня мало волнует, raid там или супернадежные SSD. Меня волнует время простоя и компенсации за него.
Если у вас так же, как у массовых недорогих хостеров типа DigitalOcean, где максимум, что светит по SLA, это компенсация времени простоя — то тут не в вашу пользу (в DO проблемы устраняются быстрее хотя бы за счет их масштаба, отлаженных годами процессов и узкой специализации на одном продукте).
Если же предоставляется нормальный SLA (пусть это будет дороже) — хотелось бы видеть условия.
Это куда лучше, чем требовать компенсаций. Или у Вас просто цель как раз в этом, чтоб заработать на компенсациях? И проект именно такой? :)
То есть, по-вашему, SLA нужен для того, чтобы требовать компенсаций.
На этом, думаю, разговор можно завершить.
Меня волнует время простоя и компенсации за него.
Это Вы сказали, что SLA нужен для того, чтобы требовать компенсаций. Не я. Ваши слова.
Меня волнует время простоя и компенсации за него.
Если у вас так же, как у массовых недорогих хостеров типа DigitalOcean, где максимум, что светит по SLA, это компенсация времени простоя — то тут не в вашу пользу (в DO проблемы устраняются быстрее хотя бы за счет их масштаба, отлаженных годами процессов и узкой специализации на одном продукте).
Если же предоставляется нормальный SLA (пусть это будет дороже) — хотелось бы видеть условия.
О чем говорить с неадекватом, который с утра одно а с вечера — другое.
То есть, по-вашему, SLA нужен для того, чтобы требовать компенсаций.
На этом, думаю, разговор можно завершить.
Если вы не видите разницы — это проблема вашего восприятия.
SLA — это гарантия. Разумеется, в идеале хотелось бы, чтобы гарантийный случай никогда не наступил, но если уж он наступил, четко прописанная в договоре компенсация — особенно когда час простоя стоит на порядки дороже, чем стоимость хостинга — важна.
Формулировка "не нужно будет думать о компенсациях. То есть не будет простоя" смешна, это из серии "мамой клянусь". В случае чего — будет "ну не шмогла я". Серьезный бизнес!
Если же Вы хотите иметь большую компенсацию — Вы оплачиваете SLA, которое может стоить от 100-200 евро в месяц дополнительно и предусматривает компенсацию, где-то на порядок больше этой суммы максимум.
Если у Вас час простоя стоит на порядки дороже хостинга — Вам следует размещать проект не на хостинге, а строить октазоустойчивое решение, вне зависимости от политик компенсации ЦОДов. В разных ЦОДах. То есть, чтоб обеспечивалась возможность беспрерывной работы в любых случаях.
хотелось бы, чтобы гарантийный случай никогда не наступил, но если уж он наступил, четко прописанная в договоре компенсация — особенно когда час простоя стоит на порядки дороже, чем стоимость хостинга — важна.
Как раз напротив.
Компенсируют вам только стоимость услуг хостинга — которая на порядки ниже вашей стоимости.
Поэтому стоимость компенсации — это всего лишь маркетинговая ловушка.
Эти копейки для типичного деньги приносящего проекта не значат ничего.
Лично мне представляется, что у хостера RAID10 и 8 1TB SSD на машине, и мне по барабану, как у него там устроено, главное чтобы у меня был uptime 99.95.
Так по статистке менее чем 1% накопителей SSD выходит из строя в первые 2 года по случайным причинам. И менее 4% — по всем остальным причинам, включая случайные. То есть более 3% из 4-х подпадает под довольно реальный прогноз именно благодаря физике SSD. В отличии от HDD, SSD убиваются циклами перезаписи и количество этих циклов вполне известно для того или иного типа твердотельного накопителя
Полагаю, это ключевая ошибка статьи. Исследование Google показывает, что SSD действительно реже выходят из строя полностью, в отличие от HDD. Но гораздо чаще теряют информацию. Ознакомьтесь, пожалуйста. А убийство SSD циклами перезаписи в текущих реалиях вообще кажется мне смешным фактом.
Нужен ли он на этих услугах? Нет, и основная причина в том...
Полагаю, что ваши объяснения на эту тему никого особо не интересуют. Есть рынок. Если ваше предложение X и предложение конкурентов Y. Вот и все. Если за ту же цену, что вы продаете сервер с SSD но без RAID я у ваших конкурентов смогу приобрести SSD с RAID, то при прочих равных я пойду к вашим конкурентам. А ваши объяснения на Хабре проигнорирую.
Мне кажется, вместо того, чтобы бороться с конкурентами с помощью статей сомнительного качества на Хабре, стоит воспользоваться советом Джека Траута:
Дифференцируйся или умирай
Научитесь, в конце концов, отличаться от конкурентов чем-то большем, чем длиной отсека для SSD и величиной цифр в прайсе.
А убийство SSD циклами перезаписи в текущих реалиях вообще кажется мне смешным фактом.
И что тут смешного?
При низкой нагрузке они живут довольно долго, однако если у Вас довольно много операций перезаписи — срок жизни может составить несколько месяцев.
30-80 percent of SSDs develop at least one bad block … in the first four years of deployment
Крутое "исследование".
Например — 0+1.
Цифрами (секунды/часы/дни).
Бекапы никто не отменял, но бекапы — это Disaster Recovery, который предполагает две вещи:
— даунтайм
— потерю данных, добавленных с последнего бекапа.
RAID — это High Availibility, когда в случае незапланированного отказа одного из дисков система оставляет данные в сохранности. В случае отказа CPU, RAM, материнской платы, БП в гипервизоре я не потеряю свои данные — в случае отказа одного из дисков я гарантированно потеряю данные, пришедшие с момента RPO.
Аналогично и с вероятностями выхода из строя SSD — мы говорим о незапланированном отказе, отказ от планомерного износа реально прогнозировать и заранее принимать меры.
Говорить о мини-кластере, конечно, можно. Только это совсем другая история, и сделать вторую виртуалку, которая «всегда содержать идентичную информацию» не настолько просто, как это звучит.
Более того, нужно не забывать в случае RAID, что контроллер в ситуации глобальной проблемы, должен успеть корректно завершить работу, если не успеет — риск есть потерять данные.
На счет:
— даунтайм
— потерю данных, добавленных с последнего бекапа
Бэкапы нынче лучше делать rsync, так что у Вас всегда может быть актуальная информация, и потеря может быть весьма незначительной.
Проекты, которым эта потеря значительна, не размещаются на VPS во все, а размещаются на выделенных решениях с репликацией.
На счет реплицирования VPS — да, это не просто, везде есть нюансы. Но сделать простую более-менее отказоустойчивую схему возможно.
Господа, всё зависит от объема бекапа, готовности архитектуры приложения к failover и стоимости простоя.
Если час простоя стоит больше 5к баксов — клиенту глубоко фиолетово на чем его сервис работает, пока это стоит разумных денег. Как только стоимость владения становится слишком большой по отношению к прибыли — ищут более дешевое решение.
Ваши предложения подходят для маленьких интернет-магазинов, блогов, форумов, которым отказоустойчивость не сильно и нужна.
У меня на старой работе клиент — крупный магазин. Сидят в Хетцнере на EX40, что ли — не помню, у них 4 диска (2 HDD в R-1, 2 SSD в R-1). Потому что время восстановления из бекапа = 12 часов. За это время они теряют денег больше, чем стоит абонплата на 2 таких сервера на год вперед + обслуживание этих серверов.
И да, они сейчас делают фэйловер в другой ДЦ. Потому что они осознают цену простоя для себя.
Есть другой клиент. Их внутренняя CRM крутится в Хетцнере, горячий резерв — во Франции, в дешевом ДЦ. Везде зеркала. Потому что 1 час недоступности этой штуки с лихвой перекрывает стоимость содержания двух серверов пару месяцев.
В текущей компании у нас балансер на 3 геораспределенных железки, стоимость аренды каждой чуть больше $200/мес. Одна сдохла — не беда, поднимем за сутки ей замену. Простой этой всей штуки 1 минуту перекрывает мою зарплату на год вперед.
А есть пара клиентов, в старой компании, которые живут на VPS за $5-$10 в месяц. Оно как-то работает, куда-то бекапится и они не парятся… Пока всё работает. Но как только что-то перестает работать — наступает ахтунг. Они, когда дорастут до предлагаемых вами мощностей, будут готовы купить две виртуалки вдвое дороже (для RAID-10), нанять спеца чтоб сделать фэйловер и админа чтоб приглядывать за этим (часов 5 в месяц).
Опять же — клиент нашего клиента — агрегатор объявлений об услугах, разругался с исполнителем (нашим клиентом) и ушел и от них и от нас. Через 2 или 3 месяца случилась жопа и они очень быстро нашли нас, заключили договор и всё оплатили. Из-за тормозов связанных с дисками. Если бы там был не рейд, то...
Совет: предлагайте два варианта — то что вы сейчас предлагаете и то же, но с RAID-1. Кому надо — купят с зеркалом, кому не надо — возьмут без.
Восстановление после простоя — это время реакции админа (для мелких — это приходящий админ) и связанные с этим репутационные риски.
Проще платить сразу за 2 сервера, это не дорого.
Еще раз: у вас 3-4 сотрудника, маленький оборот, мало клиентов. Вам не на что арендовать два сервера.
Для таких — VPS и какой-то бекап — уже редкость, обычно это — shared-хостинг за гроши без каких-либо гарантий и админа вообще.
Для тех кто может себе позволить $300+ в месяц на аренду VPS и оплату З/П админу — два сервера — подъемная задача, но владельцы считают что "это того не стоит".
Когда начальство осознает что отсутствие бекапов может стоить им бизнеса, а простой 1-2 дня приведет к опустошениям запасов спиртного в ближайшем баре — тогда нанимается более-менее серьезный админ, арендуется соответствующее оборудование, вносятся коррективы в ПО… Но это — не мелкие интернет-магазинчики и подход там совсем другой.
Теперь вот этот кусок
Восстановление после простоя — это время реакции админа (для мелких — это приходящий админ) и связанные с этим репутационные риски.
Всё зависит от проблемы. Если это залипший Апач или FPM, то да — решение находится быстро и всё возвращается на круги своя.
Но если это взлом, факап с данными или еще что-то нетривиальное, то получасовой простой превращается в многочасовой марафон.
Кроме того, не забывайте что если у вас настроен фэйловер, вам нужно его мониторить и тестировать. А это — тоже ресурсы.
Еще раз: у вас 3-4 сотрудника, маленький оборот, мало клиентов. Вам не на что арендовать два сервера.
Для таких — VPS и какой-то бекап — уже редкость, обычно это — shared-хостинг за гроши без каких-либо гарантий и админа вообще.
Не смешите меня.
При нынешних ценах-то на хостинг?
Да Вы на зарплату 3-4 сотрудников в месяц будете тратить раз в 10 больше денег, чем на хостинг за весь год.
Тут дело не столько в деньгах, а в том, что люди недопонимают технические риски, или понимают и пускают все на авось.
3-4 сотрудника — это значит у вас очень хороший поток заказов.
У меня один из клиентов как раз интернет-магазин.
Так вот чистый (за вычетом расходов) заработок в полмиллиона рублей в месяц они делают с одним сотрудником, переписывающимся с клиентами, подготавливающим посылки.
И с одним курьером.
И еще одним на подхвате (на полставки).
При затратах на хостинг порядка 3-8 тыс. рублей в месяц (затраты плавающие, так как у них автомасштабируемое облако). То есть хороший хостинг с дублированием у них это в среднем около 1% от прибыли (не от оборота даже).
И это даже избыточно, можно и дешевле.
VPS (KVM) — E5-2650 v4 (12 Cores) / 20GB DDR4 /2х240GB SSD RAID1 / 1Gbps 20TB — $49 / месяц;
VPS (KVM) — E5-2650 v4 (24 Cores) / 40GB DDR4 /2х480GB SSD RAID1 / 1Gbps 40TB — $99 / месяц;
Хотя таких нуждающихся менее 20%, как показал опрос. Большей части достаточно первых 3-х вариантов опроса:
Но мы действительно идем на встречу потребностям наших клиентов и правда очень благодарны за Ваши мнения и критику. И если 20% голосуют за такую возможность — мы удовлетворим эти потребности. Будем воплощать Ваши пожелания в реальность, ua-hosting.company — рады сделать Вас счастливее!
Вероятность безвозвратной потери гипервизора целиком много меньше вероятности отказа диска.
На случай потери гипервизора целиком как раз и есть бекапы и есть Disaster Recovery.
Отказ диска на машине — это рабочая ситуация, а на случай выхода двух дисков в RAID есть бекапы.
> Проекты, которым эта потеря значительна, не размещаются на VPS во все, а размещаются на выделенных решениях с репликацией.
Я правильно понимаю, что вы хотите сказать «в случае проблем с железом все, что у клиента останется от сервера — это бекап, кто против — пусть берет три дедика»?
Говорить о мини-кластере, конечно, можно. Только это совсем другая история, и сделать вторую виртуалку, которая «всегда содержать идентичную информацию» не настолько просто, как это звучит.
Добавлю:
И те люди, которые умеют создавать такие кластера — не являются целевой аудиторией этой статьи.
Ибо не нуждаются в столь примитивных объяснениях и тратят на хостинг куда как более весомые суммы, чтобы их могла соблазнить экономия на отсутствии RAID.
В отличии от HDD, SSD убиваются циклами перезаписи и количество этих циклов вполне известно для того или иного типа твердотельного накопителя. Потому состояние накопителей возможно мониторить и более-менее точно прогнозировать необходимость их замены. То есть статистика говорит о том, что % случайных отказов лежит примерно на уровне % потери данных по всем другим причинам, включая глобальную проблему на сервере в целом, которая ведет к потери данных.
То есть тут вопрос доверия к хостеру — а заменяет ли он диски заранее ради профилактики.
Имхо — никто не заменяет диски заранее.
Следовательно, все эти рассуждения про предсказанный % — фуфел.
Prorata: order #4653, product #4583 (30/01/2017 — 01/02/2017) в размере $0.94 возвращена Вам на баланс, не нужно было ее платить :)
Интересно выглядит принципиальная позиция по достаточной надежности отдельных дисков в угоду цене и, на фоне этого — цена платформ под эти самые VPS.
К слову, какие контроллеры задействованы в ваших серверах?
В случае более длительного периода — возможна скидка.
Для заказа сервера по такой схеме — обратитесь в отдел продаж с ссылкой на этот комментарий.
О восстановлении. Целесообразен ли RAID на VPS SSD в случае выделенных накопителей? Аналог сервера до февраля бесплатно