Я так понял брались тезисы статьи с PoiskVPS.ru и давался на них ответ, без маркетинга не обошлось конечно, но в целом на мой взгляд ответили обосновано.
«Разница в 3-4 раза не кажется страшной.»
Кому то не кажется, кому то кажется.
ARM интересное направление, но работы что бы он стал массовой технологией для того же хостинга и VPS еще предстоит очень много.
Ок. Xen?
«смешанные решения» это же не только виртуализация, там и по физике задач полно. Как пример offload backup (LAN Free), да и много чего еще.
Nutanix это хорошая система, я не спорю )
Интересные железки, вернее сказать правильная концепция и хорошо написанный софт.
Но применимость ограниченна: под VDI да круто, под смешанные решения (несколько типов гипервизоров) уже не применимо как единая система, физические сервера в пролете, для них эта система не подходит. Никаких iSCSI, FCP и т.д.
По цене, если сравнивать СХД с забивкой SSD вендоров первого эшелона + сервера для обработки, то стоимость сопоставимая или выигрывает Nutanix, а если рассматривать смесь HDD+SSD то обычная СХД.
Nutanix по скорости очень крут, хоть и не во всех сценариях применим. Но там где применим, он смотрится отлично.
Нормально все у NetApp c FCP. Проблем за очень многолетний опыт и общение с кучей систем нетаппа не встречал, именно по вине нетапп. А так был пример, что спокойно LUN шарится по FC и iSCSI и все отлично работает в общем доступе на более чем 40 хостов.
ALUA только в таком совместном использовании не работает.
«Централизованное питание и отсутствие ненужных элементов на плате повышают показатель MTBF на 58% по сравнению с традиционными стоечными системами»
Вот мне интересно как они это считали. Там надо что бы это реально отработало много времени, около 3-лет, а то как то 58% это на маркетинг похоже.
Сорри ниже ошибся с местом ответа, продублировал, а старый уже отредактировать не могу (
Конкретика простая.
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Конкретика простая.
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
19ТБ реально заюзать.
Реально заюзать и больше чем 22ТБ, использую thin provisioning и deduplication, совместное их использование даёт около 50% экономии пространства, при очень минимальном влиянии на производительность.
7 лет работаю с NetApp системами. Про заполнение аггрегата есть баг, да. За этим надо следить, по всему остальному надо понимать как система работает и знать нюансы. Надо правильно её «готовить» ) А так системы отличные, если руки и голова есть, то будут работать как часы, годами.
«Целью атакующих могут быть, как отдельные ресурсы размещенные на серверах, сами сервера и вся площадка в целом»
Если вся площадка в целом то blackhole плохой метод. Все подсети в blackhole посылать не вариант.
Опередили. Тоже не понял что за утверждение «На сегодняшний день в отрасли это максимальный объем хранения данных в рамках одного сервера.» У меня есть сервера по 18 дисков 3,5 + 2 диска 2,5 и это в 2U.
Так стелить соломку надо всегда. И иметь настроенные бекапы к себе на площадку (или к другому оператору) можно и иметь договор на возможность задействования ресурсов у другого провайдера по мере необходимости (и оплату за реальное потребление).
Что мешает это делать?
Информация что «Большинство ведущих веб-сайтов работает на базе IBM Cloud» и занимает первое место, а если перейти по ссылке не обзор то ситуация совсем другая hostcabi.net/hosting_infographic
Кому то не кажется, кому то кажется.
ARM интересное направление, но работы что бы он стал массовой технологией для того же хостинга и VPS еще предстоит очень много.
Наверное есть.
Хотелось бы приблизительно понимать, сколько такая компания в среднем зарабатывает в месяц?
«на разработку за 2 года ушло примерно 1500$»
Вот это круто ) 1500/24=62,5$ в месяц, хорошая ЗП ;)
«смешанные решения» это же не только виртуализация, там и по физике задач полно. Как пример offload backup (LAN Free), да и много чего еще.
Nutanix это хорошая система, я не спорю )
Но применимость ограниченна: под VDI да круто, под смешанные решения (несколько типов гипервизоров) уже не применимо как единая система, физические сервера в пролете, для них эта система не подходит. Никаких iSCSI, FCP и т.д.
По цене, если сравнивать СХД с забивкой SSD вендоров первого эшелона + сервера для обработки, то стоимость сопоставимая или выигрывает Nutanix, а если рассматривать смесь HDD+SSD то обычная СХД.
Nutanix по скорости очень крут, хоть и не во всех сценариях применим. Но там где применим, он смотрится отлично.
ALUA только в таком совместном использовании не работает.
Вот мне интересно как они это считали. Там надо что бы это реально отработало много времени, около 3-лет, а то как то 58% это на маркетинг похоже.
Конкретика простая.
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Пример аггрегат 20ТБ,
Создаём 10 volume по 1ТБ каждый (с возможностью роста до 2 ТБ или тонкие), тип поступа SAN
На vol включается дедупликация
На каждом из этих vol делается по одному Thin LUN на 2ТБ.
Итого мы на системе заняли 10ТБ 50% места (от 20ТБ), но при этом получили 20ТБ для записи данных, с учетом что thin и дедупликация экономят в среднем до 50%, вы туда реально около 18-20ТБ и запишите в зависимости от типа данных. Если данных будет больше, ваши vol автоматически расширятся. А так как у вас место еще есть то можно в рамках 20-25% создать еще LUN'ов по такой же схеме, и при этом не выйти за порог падения производительности в 90% заполненности аггрегата.
Как то так )
Реально заюзать и больше чем 22ТБ, использую thin provisioning и deduplication, совместное их использование даёт около 50% экономии пространства, при очень минимальном влиянии на производительность.
Если вся площадка в целом то blackhole плохой метод. Все подсети в blackhole посылать не вариант.
Что мешает это делать?
То есть вы априори считаете, что своё никогда не ломается?