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

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

Какие-нибудь плагины используете?
Пока нет, но будет асинхронная репликакция точно
Что-то мне кажется, что правильный подбор железа + вполне бесплатные решения с ZFS на (Open)Solaris или даже FreeBSD ничем особо не уступают. Вместо гуя будет консоль, но простота использования ZFS вполне доступна любому, даже кто с самим солярисом знаком слабо.

$1.7k по сравнению со стоимостью железа в $10k не так заметно, но это потому, что этот файлер с производительными дисками небольшого объема. Для файлера на SATA дисках в 3Тб стоимость его самого будет ниже, а лицензии — выше (лицензируется же по объему). При этом, платность софта не дает никаких гарантий, что выбранная аппаратная конфигурация будет работать хорошо, даже если она соответствует HCL. За что платить-то, за поддержку веб-админки? Уж лучше тогда решения от Oracle — там хоть железка с ZFS, а не просто лицензия на софт.

На мой взгляд главную проблему представляет собой железо. Таймауты дисков, поведение контроллеров при таймаутах дисков — все это может сделать обычную ситуацию с вылетом диска вполне фатальной — отвалится от перегрева контроллер Адаптек по таймауту, просто воткнет система секунд на 30… Многие enterprize NASы — это довольно обычное х86 железо, харды от Seagate, но денег стоят за совместимость, за протестированные конфигурации, за прошивки хардов с правильными таймаутами, и пр. Я бы не отказался увидеть список железа, из которого можно собрать хороший опенсорсный файлер
Полезное решение от Oracle будет стоить 3к в год долларов за поддержку и 10к долларов за только железку (без дисков).
Диски вообще золотые будут (у них стоимость 2008го года на диски за гб).
Зато там будет active active репликация.

Правда что-то мне подсказывает FreeBSD сделает это бесплатно с HAST :).

Единственная проблема в FreeBSD — отсутствие нормального iscsi.
Так бы на ней можно было бы собрать true multi-tier сетевое хранилище, где каждый диск был бы, например atom с райдом 4тбх2.
в общем кому танцы с бубном и много свободного времени, то можно позаниматься.
а мы лучше заплатим $1750 за Нексенту и запустим все за недельку. С учетом зарплат админов это сильно дешевле.
В продакшн имеет смысл взять Gold support — оно того стоит. Серьёзные проблемы гораздо быстрее решать через Gotomeeting/Webex, чем через почту.
Никаких танцов с бубном, все есть в онлайне :)
Архивное хранилище мы делаем именно по этому рецепту, там солярка, 15х3тб диски wdc red, один контроллер с экспандером и никаких GUI. Но это тема отдельного поста, я подробно отпишу конфиг машины. Кстати собрали нам ее опытные парни по солярке за 200 баксов.
А для нексенты основная идея что нельзя эксперементировать, должно быть отшлифованное решение. Если архивный том пару часов посидит в офлайне, ничего не случится. А центральное хранилище такого не может допускать.
Касательно мелких контроллеров, по опыту мы еще ни одного не поменяли по гарантии. А их у нас много.
На случай ахтунга — есть снапшоты тома и отдельно каждой ВМ. Через то и спасемся ;)
Почти любой сторадж на новом железе работает неплохо. Вполне логично, иначе кто б такое железо покупал? Или пока температура в ДЦ 18 градусов, и все вентиляторы в сервере новые. А вот через 3 года дуть будут хуже, а температура повысится, контакты шлейфов окислятся, у ssd закончится лимит ремапинга на запись, харды начнут разваливаться и тупить по 10 секунд в попытке отремапить битый сектор (к хардам raid edition это относится меньше, а к sas вообще почти не относится, но тем не менее). Вот как СХД поведет себя тогда? И если выяснится, что supermicro с adaptec покупать не стоило, то бюджетов на исправление таких ошибок может и не быть
3 года долгий срок. Скорее всего значительно раньше мы сделаем более адекватный и современный файлер рядом, смигрируем на него данные. А старый файлер модернизируем или будем использовать в другом режиме. Представьте себе что за файлер и на чем вы могли собрать в 2009 году? Сейчас все гибко, подцепили новый том на ноды и смигрировали.
Вы написали про линейное чтение-запись. Но мы прекрасно знаем, что виртуализация с большим количеством ВМ это почти 100% рандом. А линейка нужна только в узком кругу задачь типа бекапа и видео обработки. А для этих задачь можно было все это не городить.
Выполните пожалуйста тест на рандом. Тем же ioMeter.
Размер сета в ioMeter ~800GB-1000GB (заведомо для частичного пробития кеша).
1) 100% рандом, чтение. Блоки 4К.
2) 100% рандом, чтение 50%, запись 50%. Блоки 4К.
Когда я тестировал Nexenta (года 2 назад) то скорость была убогая на рандом, в том числе при использовании SSD кеша на запись и чтение.
Так же есть опыт на Starwind, не без косяков, но весьма положительный в формате active-active под большой нагрузкой.
Ждем тестов )
Однако с дедупликацией и мемори кэшем говорить о 100% случайном чтении не совсем верно при массовой виртуализации с 5-6 шаблонов… Все что часто используется и фрагменты ОС будут именно оттуда раздаваться, а механизм copy-on-write и запись сводит к тому же. Так что тут синтетикой не проймешь что и как будет. Том на 1Т мы гоняли тестами, там было ожидаемые 3000-4000 iops в одну линию, там же 35 дисков. Ровно столько и должно быть, тут без чудес волшебных. Картиночку пришлю ;)
По опыту — 350 виртуалок == 1000 iops в рабочем режиме на старвинде и hyper-v/csv
Кстати на картинке есть циферки про random read/ write в один поток и в 32.
Интересная статья с точки зрения реального продакшен использования zfs.

Но есть вопросы:
Почему raidz, а не миррор? У вас же чтение превалирует. Заранее сравнивали? Что показывали тесты?
Насколько используется l2arc?
Один SSD на 300Gb серверного класса Intel 710, это центральный кэш ZFS. Бытовые не годятся, выгорают на раз.
Пробовали или теоретизируете? Если пробовали, кто умирал и после какого времени и скольких записанных данных?
Какой размер дуплицируемых данных и какой коэффициент экономии?
Используемые ли компрессию?
Какие диски используете под zil? Сколько на них приходится иопсов и мегабайт в секунду на запись?
Ну по пунктам…
Зеркало дороговато выходит, нам и объем важен.
По поводу ssd на 300гб, тут не надо пробовать и обжигаться. Опытные люди говорят что нужен серверный ssd или будут проблемы. У нас коммерческая эксплуатация, а не тестовая лаба — мы слушаем экспертов вендора и делаем как они рекомендуют.
Компрессию не используем.
По поводу остального напишу отдельный пост после того как перемигруем туда все виртуалки и система встанет на полную нагрузку
Ясно. Жду следующего поста с развернутыми ответами :)

И еще: умирание диска(ов) с l2arc некритично для данных, а вот объем и количество дисков быть может критично для производительности.
да, мы в курсе. SSD кэша и логов могут совсем сдохнуть, только скорость снизится немного. потом с консольки их меняем и все хорошо дальше. Главное что бы сами диски были на хот-свопе и легко доступны для замены.
Компрессию не используем.

А вот это вы зря. Компрессия (on/lzjb) практически ничего не стоит с точки зрения CPU, но места может сэкономить достаточно много (для виртуалок, 1.5х compress ratio — запросто). В отличии от дедупликации, которой нужны дорогие SHA256 вычисления для каждого I/O, и большой кеш.

С gzip всё будет медленно, да, он подходит только для архивов, где производительность не особо важна.

Опытные люди говорят что нужен серверный ssd или будут проблемы.

Подтверждаю :) 710 или 520 — нормально для standalone системы; всякие там 320/311/… нормально работать не будут, или будут, но недолго.
Ну раз разработчики так говорят, то глядя на 30-40% загрузки проца пойду включу, благо что это делается наживую. Попробуем.
По дедупликации я жду коэффициента около 10, после переноса туда виндовых впс. Но это тема отдельного поста примерно через месяц.
А что, у ZFS уже починили беду с удалением дедуплицированного тома, которое вешает всю систему?
Починили в версии 4.0 Нексенты (сам код написали ребята из Delphix, и закоммиттили в Illumos). Фича называется «asynchronous destroy».
И еще вопрос:
Есть ли у вас инструкция и какие ваши действия в случае умирания, скажем, материнки, сетевой карты или hba карточек?
Да, конечно. Мы в вопросах эксплуатации полагаемся на свою статистику по авариям и гарантии (1000 серверов на балансе), она гласит следующее:
1) блоки питания современных серверов не ломаются
2) мать Supermicro последнего поколения можно испортить совсем только неправильно поставив или подключив. Иногда она сразу не заводится или глючит — младенческая смертность. Все остальные случаи бывают после 3-4 лет работы
3) память не портится в матери
4) контроллеры имеют AFR менее 1%, шансы его сдохнуть при работе ничтожны
Вместе с тем, у нас в шкафу или свободных серверах всегда есть схожие запчасти и аналогичные контроллеры, что позволит придать рабочий конфиг файлеру за час-два.
Для катастрофических ситуаций есть снапшоты на другой машине
Да, чувствую, по вашему списку, вам еще многое предстоит узнать :)
Все меняется и мы постоянно узнаем что-то новое. Данные в комменте сверху это опыт закупок, гарантийных случаев и аварий на протяжении 4 лет при эксплуатации более 1000 единиц разномастных серверов. Этот опыт позволяет нам минимизировать проблемы при эксплуатации и иметь надлежащий цикл у серверов от закупки до продажи по выслуге лет. Если что, все закупки и гарантия проходят лично через меня. А сколько серверов у вас в эксплуатации?
> блоки питания современных серверов не ломаются
> мать Supermicro последнего поколения можно испортить совсем только неправильно поставив или подключив
Сервисные инженеры с опытом уже начали тихонько ржать в кулак.

> память не портится в матери
www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

> контроллеры имеют AFR менее 1%, шансы его сдохнуть при работе ничтожны
На популяции в 1000 серверов, AFR 1% означает минимум 10 сдохших контроллеров в год.

Вообще я считал, что в нашей отрасли пессимизм, порой приправленный изрядной доли паранойи, издревле считается хорошим тоном,
а оптимизм уровня «AFR 1% — да это же так ничтожно мало! А два диска разом в RAID-группе не выходят из строя никогда, использовать RAID-6 бесмысленная трата средств!» это явный моветон. Кажется я ошибся ;)
Ну мы 5 рэйд тоже не используем если что ;)
А так, как то я имел дело с сервисом, где мы тогда занимались контрактными запчастями для японских авто. Так нам каждый день приводили машины на эвакуаторе с двигателями в сборе на замену. Значит ли это что японские двигатели часто ломаются?
Просто по опыту я за все время сдал по гарантии один блок питания интеловского сервера и два блока с асуса позапрошлого поколения на 771 сокете.
За последние 2 года как мы с целом перешли на Супермикро, может 1-2 матери меняли. У нас всегда в наличии запчасти, раз мы клиентам даем СЛА в 4 часа по железу.
Ну мы 5 рэйд тоже не используем если что ;)

Ну так и я об этом.

Но речь о том, что вы не ориентируетесь на worst case, что, в нашем деле, считается почти общепринятым.
Просто, искренне скажу, удивительно видеть серьезную (типа) компанию, которая ориентируется на «нам повезет, мы везучие, у нас ничего не ломалось, значит и впредь не сломается»
Ну мы 5 рэйд тоже не используем если что ;)

Так raidz — это и есть Raid5, грубо говоря. Несколько raidz групп в одном пуле — получается аналог Raid50. То, что группы маленькие, по 3 диска — это хорошо, там вероятность потери 2х дисков в группе из 3х небольшая, не больше чем потеря 2х дисков в одной mirror группе. Но тем не менее, она есть, так что регулярные бэкапы всё равно необходимы.
Да, все эти касается только техники которую мы эксплуатируем и закупаем. Я понятия не имею о статистике выхода из строя hp, IBM и т.п. Но речь про наш новый файлер, он собран из понятных нам компонентов.
Исправьте — 4U шасси
ага, опечатался
Емкость пула можно расширить в любой момент добавлением новых дисков. Это не драматическое событие при расширении RAID6 емкостью 10Tb на традиционном контроллере, вы просто добавляете еще дисков и система начинает их использовать. Ничего не перестраивается, данные никуда не перемещаются.

На версии 3.1.3.5 расширение пула делать не советую, особенно когда он почти забит данными. Там используется достаточно старый алгоритм аллокатора, который не делает правильную балансировку на vdev'ы разной степени заполненности. Когда выйдет 3.1.4 или 4.0, можно проапгрейдиться, там новый алгоритм, который это учитывает.

Enhancement 12379: Enhanced the ability of ZFS to handle imbalanced LUNs which can occur when a user has grown zpools after creation which could have led to poor performance.
вот-вот должна 4.0 появиться. Мы ждали что она появится до конца февраля, но увы, релиза не было и пришлось ехать в дело с 3.1.3.5. Надеюсь когда 7Тб с учетом дедупликации забьются, это не вызовет проблем. В любом случае, мы не планируем заниматься этим самостоятельно — есть специально обученные сертифицированные по Нексенте инженеры у партнера которые нам помогут и которые в курсе всех косяков.
Окей, замечательно. Только «в курсе всех косяков» — понятие растяжимое. У партнёров пока нет прямого доступа в наш внутренний багтрекер, так что с некоторыми косяками они могли и не встречаться. Особенно с точки зрения производительности — есть некоторые мелочи, которые могут её поднять в разы, если известен workload.

Например: правильная настройка mpxio (scsi_vhci.conf), размер блоков на LUNах (достаточно нетривиально понять, что больше подходит), правильные параметры для ZFS в /etc/system, и так далее.
ну тогда точно придется брать Gold support и пускать инженеров Nexenta с отвертками и паяльниками в потроха нашего файлера для его полного тюнинга и прокачки =) Самое главное мы его сейчас под нагрузку поставим и там профиль загрузки будет ясный. Пока крутить там нечего, а через месяц очень будет даже интересно посмотреть внимательнее.
Удачи. Если кейс до меня дойдёт, постараюсь помочь :) В лабе есть система практически идентичная вашей, только диски 450ГБ.
Очень интересно, спасибо за рассказ!

Скажите, а SSD вы в отсеки для дисков монтировали (т.е. тратили места), или просто в полостях корпуса разложили, благо, они некрупные и не особо капризные к монтажу?

P.S. Если не секрет, а почему со Storedata ушли?
мы купили дизайнерскую штучку на 2 диска 2,5" от Agestar за 500р в никсе, она отлично встала в 3,5" слот супермикры. если приглядеться, ее видно на фотке, торчит вперед немного.
мы знаем что они расходные, потому внутрь класть не стали что бы не лазить на живую. а подключены они на адаптек, что бы хотсвоп был.
со Стордаты ушли по причине цены, мы получили хорошую цену в Мегафоне и за 3 месяца переехали. А так Стордата хороший ЦОД, претензий не имеем.
бесплатная версия без поддержки на 18Тб. Все то же самое, но без полезных и нужных плагинов.


Расскажите пожалуйста, каких именно полезных и нужных плагинов там нет?
Из бесплатных плагинов там нет AutoSync (для асинхронной репликации); платных плагинов для Community Edition нет в принципе.
Я весьма мало понимаю в нексенте, но правильно ли я понял из документации, что AutoSync есть механизм репликации между двумя железками и в реальной жизни не особо нужен в масштабах одной единственной железки?

А какие еще плагины нужны в реальной жизни хостинга (именно хостинга, а не в корпоративной среде, например, банков)?

Для Community Edition есть куча бесплатных плагинов, но при беглом просмотре списка я не увидел ничего полезного. Может быть, кроме ATA-over-Ethernet, но учитывая распространённость этой технологии…
Я весьма мало понимаю в нексенте, но правильно ли я понял из документации, что AutoSync есть механизм репликации между двумя железками и в реальной жизни не особо нужен в масштабах одной единственной железки?

В принципе да, он для репликации между железками, но его можно использовать и для Local to Local репликации. Например, делать бэкапы с быстрого 15к пула на медленный пул из 2-3-4ТБ дисков.

А какие еще плагины нужны в реальной жизни хостинга (именно хостинга, а не в корпоративной среде, например, банков)?

Для хостинга имеет смысл взять HA Cluster, и может быть FC Target, если планируете делать Fibre Channel. Есть ещё VMDC, но он практически бесполезен если есть vCenter или Xen Enterprise.
> Например, делать бэкапы с быстрого 15к пула на медленный пул из 2-3-4ТБ дисков.

А чем он лучше для этого, чем rsync? Более того, в документации утверждается, что rsync лучше:

auto-sync over rsync
As far as auto-sync over rsync, note that rsync transport provides a number of benefits
compared to 'zfs send/receive'. Unlike zfs send/receive, rsync is a true application level
protocol on top of TCP. Both rsync client and server are multi-threaded, performance optimized.
Using rsync often means getting a better performance

Зачем тогда это (если rsync я и в голом виде умею настраивать)?

Контекст вопросов — я давно пытаюсь понять практический смысл платной нексенты и с какой стороны в документацию не смотрю — получается, что либо надо больше 18 терабайт, либо не надо, и это единственный реальный критерий. Или я чего-то не учитываю? (Кроме случаев больших масштабов, когда действительно Fibre Channel и остального такого размаха, что цена нексенты несущественна и можно купить просто на всякий случай)
А чем он лучше для этого, чем rsync? Более того, в документации утверждается, что rsync лучше:

AutoSync использует ZFS send/receive, и передаёт измененные блоки между снэпшотами. Rsync смотрит на каждый файл и передаёт изменённые файлы. Так что rsync не сможет ничего сделать с iScsi/FC zvol'ами. Кроме того, rsync сам работает поверх ssh, так что он обычно медленнее, особенно для репликации между удаленными сайтами. И, поскольку он работает с файлами, он не очень подходит для репликации, если на системе миллионы маленьких файлов.

Контекст вопросов — я давно пытаюсь понять практический смысл платной нексенты

Тех-поддержка и помощь с настройкой. Если вы интимно знакомы с ZFS и Солярис, делайте систему на OpenIndiana или OmniOS. Принцип здесь тот же как и XenServer vs. XCP, или Redhat vs. Centos. Для небольших систем имеет смысл купить поддержку, особенно если в компании нет никого, кто может нормально настроить и поддерживать систему вручную.
rsync обычно работает сам по себе поверх TCP, ssh там очень опционально. Но синхронизация файлов (которым надо хеши считать) vs блоков (у которых, наверное, есть карта с таймстемпами последних изменений) — это понятно.

А что, кстати, у нексенты с тех-поддержкой на русском и с русской бухгалтерией?

В компании есть, кто может настроить до нужного состояния что угодно. Но у меня нет понимания длительности процессов в обоих случаях, и есть подозрение, что поставить нексенту будет быстрее. С другой стороны мы разработчики, поэтому если есть что-то критично важное [нам] — может получиться дешевле любую альтернативу доразвить до любого уровня, чем покупать платную версию, где что-то все равно будет для нас не идеально. С OpenVZ, кстати, у нас так и получилось.
rsync обычно работает сам по себе поверх TCP, ssh там очень опционально. Но синхронизация файлов (которым надо хеши считать) vs блоков (у которых, наверное, есть карта с таймстемпами последних изменений) — это понятно.

Ну да, примерно так и есть — изменённые блоки в ZFS получить очень легко. Исторически, send/receive был написан одним парнем в Sun, которого сослали в Китай, и он таким образом решил проблему с синхронизацией репозитория кода Solaris между локальной системой и главным офисом. :)

А что, кстати, у нексенты с тех-поддержкой на русском и с русской бухгалтерией?

Первый уровень тех-поддержки и бухгалтерия сейчас работают в основном через местных партнёров, насколько я знаю. Поскольку продажи в России растут, возможно скоро будут и местный саппорт, и бухгалтерия, но непонятно, когда. Ну и я тоже в тех поддержке (L3), если проблема сложная. А так, ребята могут и Google Translate использовать.

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

Скорее всего, да, быстрее. Solaris всё-таки сильно отличается от Linux. Доразвить альтернативу — это примерно как выбрать Gentoo вместо того, чтобы купить Redhat. Иногда имеет смысл (например, создатель OpenIndiana работает в EveryCity Hosting, и изначально строил систему для внутреннего использования); иногда — нет.

It depends ©.
Поставил NexentaStor Community Edition, все в общем ок, кроме того, что совсем нет никакой интеграции с доменом на samba+ldap
отдельно ldap работает, cifs тоже работает, но в папки не зайти т.к. как проверять пользователей из домена nexenta не знает.
Интеграцию с LDAP (non-AD) настроить в принципе можно, из командной строки. Если надо, я могу найти как это сделать.
интеграция с ldap проблем не вызывает никаких. Она есть и работает. Система видит пользователей из ldap, nfs корректно рабоатет и «метит» файлы правильными uidам\gidами, но cifs не знает о домене. И если вы знаете, как его «ввести» в мой non-AD домен — буду рад
Ага, понятно. Проблема тут как раз в том, что kernel CIFS поддерживает только Active Directory. Чтобы система работала с другими LDAP доменами, надо использовать Samba (smbd) вместо CIFS (SMF smb/server), что достаточно нетривиально настроить, и официально не поддерживается для Enterprise. После этого, насколько я понимаю, конфигурация домена задаётся в smb.conf. К сожалению, помочь с этим никак не смогу — я Самбой никогда не занимался.
Печально. Ну в общем CIFS я отключил, и нормальную smb ввел в домен и запустил. Все работает, но без gui и прочих плюшек…
Да, gui с Самбой не работает, и вряд ли будет работать (может быть в далёком будущем). Ещё одна деталь — чтобы CIFS убрать полностью (то есть, чтобы никто не мог его случайно опять включить — имеет смысл удалить конфиг сервиса ис SMF: svccfg delete smb/server.

Если надо, сервис потом можно восстановить: svccfg import /var/svc/manifest/network/smb/server.xml
Не очень понятно зачем SSD на Adaptec'е. Просто был?
А есть какой-то апдейт по этой теме? Как оно в долгосрочной перспективе?
ну там у меня есть топик как оно было через месяц работы. мы убрали оттуда тома Hyper-V, все работает стабильно уже пару месяцев. Определились с объемом, не нужны там 600Гб SAS диски, не нужна платная нексента. вероятно будем в дальнейшем делать системы на 24x1Tb raidz1, 12 групп по 1Тб + 100Gb SSD на входе. потом уже софтовым способом таргеты миррорить и на уровне самих ВМ бакапить/гонять между томами.
О, а напишите об этом подробней. Почему в итоге пришли именно к этой конфигурации, почему раньше группы делали по 3 диска, а сейчас решили по 2? Какие еще были проблемы, кроме много где описанных с местом и дедупликацией?
Ваши топики практически единственные, в которых хоть как-то описывается реальный опыт работы с N.
пояню — мы видим паттерн использования дисков и IOPS, которые приходятся на дисковую группу. Для наших утилитарных задач и показателей нет смыла в использовании 15К дисков. Нет больше смысла делать группы по 3 диска — IOPS там будет как на одном, а место мы решим просто поставив диски побольше.
Наша система уравнений видимо пока оптимально решается как я описал выше. Нет смысла городить сложную СХД, когда 90% задач можно решить одним-двумя уровнями выше — миррором iSCSI таргетов через LVM/md, бакапом ВМ, снятием снапшотов ВМ и копированием их на другой вольюм.
Т.е. я на текущий момент не вижу смысла усложнять конструкцию СХД, когда можно все решить простыми путями и бесплатно с точки зрения софта. Для наших виндовых задач Нексенту использовать нельзя, мы будем использовать родные Storage pools с локальными DAS. Как показали лабы — все работает в норме, не надо ничего придумывать.
Прочитал Ваш новый пост. Вы тут пишете, что для виндовых задач будете использовать родные Storage pools, а из поста выходит, что вы частично вернулись на StarWind. Мне инетерсена тема поддержки SMI-S софтовыми софтверными решениями. А Storage pools (и Storage Spaces) имеют к этому отношение.
В общем, хотелось бы подробностей как оно у вас сконфигурировано. Если не секрет, конечно.
ну мы сделали лабу на SP уже после всех этих дел. Возврат на Старвинд напоминал эвакуацию и проходил через диски самих нод, которые мы сделали без кластера. Сейчас мы планируем как жить дальше, и общая концепция SP нас полностью устраивает, тем более что там есть некоторая дедупликация.
Собрано будет прозаично — 24 SAS 10K диска в зеркале через HBA и понеслась в качестве основного пула и такой же рядом на SAS 15K. SATA эта штука не разумеет, с SSD будет непросто. Но по паттерну это в общем и не надо, все отлично памятью кэшируется — на ВМ и 7000 и 10000 IOPS бывает.
Лаба еще не закончена, продолжаем наблюдение.
как только закончим — напишу подробный пост. Мы вообще будем публике просто давать доступ в VMM через личное частное облако без ограничения ресурсов и тарифицировать по фактическому использованию ресурсов поденно.
Спасибо, что делитесь опытом! Это очень ценно. Буду ждать новостей )
Самое главное ограничение у бесплатной версии, это то, что Production use is not allowed with Community edition. It is designed and intended to help people become familiar with the product or for personal use.

в продакшене ее использовать нельзя, что для меня полностью убивает ее ценность :(, искал замену nas4free.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий