Есть рекомендации по настройке, но никто ж не может проконтролировать как вы это настроите.
Подсчёт делается производителем СХД для доступности своих СХД, а как вы это настроите с серверами, потом, производитель не знает. Подсчёт ведётся о доступности СХД, а не сервисов. Оно и логично — а вдруг вы взяли и сами уронили ваш сервис, так что считать что СХД теперь недоступна?
Но у всяких Нексант и МСА нет даже подсчёта уровня доступности (по простой причине — цифры не очень привлекательные).
Ещё раз — если вас и ваше РУКОВОДСТВО устраивает нексанта, МСА, Cepch или ещё что-то подобное — пожалуйста, я вас отговаривать не стану. Я ж незнаю, может вы мегаспец по этим продуктам и можете доступность обеспачить своим приложениям програмным уровнем выше всяких там мегабрендов.
Но практика показывает, что компании у которых есть отличные, высокооплачиваемые специалисты платят сотни тысяч долларов или даже миллионы за брендовые продукты именно из-за высокой доступности и отказоустойчивости «из коробки».
Главное чтобы вы и ваше РУКОВОДСТВО понимало и разделяло все связанные риски с тем, что используются дешевые/бесплатные и соответственно не высокодоступные решения.
Тогда все ок.
Потому что, как правило получается так: Деньги сэкономил босс, а за неработоспособность несет ответственность админ. И если админ достаточно опытный, то он:
или выбьет хороший (и дорогой) сервис, будет иметь в штате программёра который будет в этом продукте хорошо разбираться и при необходимости сможет искать и фиксить баги
или стнет рогом и не даст купить фигню
или напишет письмо на руководство и распишет все риски (здесь опять таки нужен хороший опыт), чтобы если начались проблемы он потом не оказался на улице с ужасными рекомендациями и соответствующими записями в трудовой.
По поводу тёплой ламповости «энтерпрайзности»:
Вот для вас лично будет разница между хранилищем NetApp с доступностью > 99,999%
И хранилищем Nexenta, которое продаётся с 2005 года, но подобной информации о доступности до сих пор нет?
Кстати о птичках, тут в коментахnavion упоминал про MSA. Знаете почему по MSA нет исследований по высокой доступности? Потому что очень много было случаев когда MSA превращается в кирпич после перепрошивки.
Другими словами SAS, как протокол для подключения СХД к серверам, для роста и расширения, скажем так, не самый лучший вариант.
Собственно это и наблюдаю в ЦОДах — его там просто нет.
Если они мигрируют из-за санкций, то из-за санкций, а не из-за того, что они этого хотели, и только те, что под санкциями а не «все везде».
И вот здесь стоит подумать, «жужжат или не жужжат» — скорее тихо скрежещут зубами и переезжают, потому что приходится. И вообще, они «уже пользуются» или «переезжают»?
А по поводу 1С в мелких конторах, я вам дал намёк в предыдущем коменте, что я их вообще не рассматриваю.
Если на то пошло, так давайте в оборот ещё возьмем вебхостинги :)
О, это же моя любимая тема — сравнивать «ZFSы» и «нетапы» :)
Вот как бы вы отреагировали, если бы вам предложили сравнить колесо и автомобиль?
И так на полном серьёзе: «а какие у тих различия в ТХ?»
Вы же понимаете ведь, что ONTAP это СХД (физическая/виртуальная/облачная), а ZFS это файловая система?
Даже если пытаться впихнуть не впихуемое сравнить не сравнимое, то для начала, стоит уточнить какое именно колесо:
то что внутрях «Oracle ZFS Storage ZS»,
то что в Nexenta,
то что в FreeNAS,
или то что на FreeBSD или Ubuntu (и других дистрибутивах)?
И справедливости ради какая именно машина будет сравниваться (Пускай код у всех ONTAP и однинаковый, но платформа разная):
та что на платформе FAS,
в виде виртуальной машины,
или та что в публичных облачных провайдерах Amazone/Azure ?
Я видел в продуктиве ритейлеров и банков (т.е. это не того размера предприятия, типа ООО «Вася Пупкин») только одну опенсорсную СХД — MySQL.
А все юзют Оракл и MS SQL и не жужжат про опенсорс.
Вы используете Ceph на продуктиве, к примеру хотябы для 500 пользователей?
Не воспринимайте это как выпад против вас или продукта Ceph, просто некоторые вещи применимы не для всех. Вот если вы облачный провейдер, то наверно, для вас это будет интерестно. А если вы обычная компания, то вам, наверное, не стоит этого делать, потому что это нужно запустить это в эксплуатацию, поддерживать и не дай Бог восстанавливать.
Ceph и любые другие опенсорсные продукты без поддержки и армии программеров для продуктивный решений стремно использовать.
А вот большие облачные провайдеры могут себе это позволить юзать.
Если знать историю ZFS, то правильнее наоборот:
Nexanta альтернатива ONTAP, так как ZFS использует часть кода WAFL и появилась, соответственно позже.
А ZFS в свою очередь был экспроприирован SAN/Oracle
Зато последний выплатил нетапу не малую суммы, но получил разрешение юзать его дальше, потому-что, к тому времени, новая кластерная версия WAFL уже шагнула далеко вперед
И посмотрите где Nexanta, а где флагманский продукт ONTAP:
Первый пытался занять нишу, в то время как ONTAP живет и здравствует.
Потому-что все версии ONTAP на всех платформах одинаковый код юзают.
Лицензии бессрочные, потерабайтные. Техподдержка покупается отдельно.
Всё-равно будет доступно в агрегате столько, сколько куплено
В качестве дисков пробрасываются RDM или vmdk, внутри это видно как диски из которых собирается RAID0, поверх создается агрегат и вольюмы поверх агрегата.
Есть 90 дневная трал версия на 20ТБ
Конфигурация виртуальной машины и количество виртуальной памяти и ЦПУ увеличить можно, но в этом нет смысла потому что ONTAP будет использовать только то что ей нужно. С хутшими параметрами не будет работать
Система будет работать без рейд контроллера но нетап не тестировал такую конфигурацию и не знает будет ли это работать оптимально и будет ли работать вообще.
Кстати некоторые вендоры софта резервного копирования отказались от бэкапа напрямую в облако (в тот же Amazon S3). Хотя такая функция ранее поддерживалась.
К примеру Veeam 9 B&R. Не знаю всех деталей почему, но одини из аргументов звучал так:
первый — не очень всё ок с безопасностью
второй — крайне мало заказчиков это юзали (наверное из-за пункта 1)
SnapMirror, в том числе SnapMirror to Tape является торговой маркой и проприетарной технологией NetApp, которая доступна ТОЛЬКО с оборудованием NetApp.
Указанные максимальные параметры производительности с включённым дедупом и компрессией и максимальной набивкой дисков. Максимумы здесь.
Программы гарантирования скорости нет.
navion AVA абсолютно другой продукт нежели ONTAP.
В то время как ONTAP заточен на случайный доступ небольшими блоками (Виртуализация/БД и др. приложения)
AVA заточена на последовательную запись/чтение для обеспечения высокой скорости линейной записи бэкапов.
В Backup режиме скорость чтения/записи
AVA800 9.2TB/hr
AVA400 6TB/hr
По CommVailt/TSM: не все заказчики могут себе позволить лить в публичное облако, плюс в AVA есть встроенная функция аппаратного онлайн дедупа/сжатия, шифрования и DR функционал в публичном/частном облаке. продукты TSM, CommVault не умеют принимать SnapMirror, так как это функция исключительно оборудования NetApp. Указанные продукты умеют управлять репликой SnapMirror между двумя хранилищами NetApp, в этом свете поддержка SnapMirror на стороне AVA будет весьма полезна: бекап будет литься с основного хранилища NetApp напрямую в AVA минуя собственно хост который бэкапируется и минуя Proxy-сервер, что позволит существенно ускорить процесс бэкапирования, в то время как софт резервного копирования будет только лишь управлять этим процессом.
Подсчёт делается производителем СХД для доступности своих СХД, а как вы это настроите с серверами, потом, производитель не знает. Подсчёт ведётся о доступности СХД, а не сервисов. Оно и логично — а вдруг вы взяли и сами уронили ваш сервис, так что считать что СХД теперь недоступна?
Но у всяких Нексант и МСА нет даже подсчёта уровня доступности (по простой причине — цифры не очень привлекательные).
Ещё раз — если вас и ваше РУКОВОДСТВО устраивает нексанта, МСА, Cepch или ещё что-то подобное — пожалуйста, я вас отговаривать не стану. Я ж незнаю, может вы мегаспец по этим продуктам и можете доступность обеспачить своим приложениям програмным уровнем выше всяких там мегабрендов.
Но практика показывает, что компании у которых есть отличные, высокооплачиваемые специалисты платят сотни тысяч долларов или даже миллионы за брендовые продукты именно из-за высокой доступности и отказоустойчивости «из коробки».
Высокая доступность СХД это вам не расчёт MTBF на диске.
Почитайте как это делается в энтерпрайзе в отчёте IDC — расчёт ведётся по всем проданным системам за какой-то срок, к примеру прошедший год.
Тогда все ок.
Потому что, как правило получается так: Деньги сэкономил босс, а за неработоспособность несет ответственность админ. И если админ достаточно опытный, то он:
тёплой ламповости«энтерпрайзности»:Вот для вас лично будет разница между хранилищем NetApp с доступностью > 99,999%
И хранилищем Nexenta, которое продаётся с 2005 года, но подобной информации о доступности до сих пор нет?
Кстати о птичках, тут в коментах navion упоминал про MSA. Знаете почему по MSA нет исследований по высокой доступности? Потому что очень много было случаев когда MSA превращается в кирпич после перепрошивки.
Собственно это и наблюдаю в ЦОДах — его там просто нет.
И вот здесь стоит подумать, «жужжат или не жужжат» — скорее тихо скрежещут зубами и переезжают, потому что приходится. И вообще, они «уже пользуются» или «переезжают»?
А по поводу 1С в мелких конторах, я вам дал намёк в предыдущем коменте, что я их вообще не рассматриваю.
Если на то пошло, так давайте в оборот ещё возьмем вебхостинги :)
Вот как бы вы отреагировали, если бы вам предложили сравнить колесо и автомобиль?
И так на полном серьёзе: «а какие у тих различия в ТХ?»
Вы же понимаете ведь, что ONTAP это СХД (физическая/виртуальная/облачная), а ZFS это файловая система?
Даже если пытаться
впихнуть не впихуемоесравнить не сравнимое, то для начала, стоит уточнить какое именно колесо:И справедливости ради какая именно машина будет сравниваться (Пускай код у всех ONTAP и однинаковый, но платформа разная):
Я видел в продуктиве ритейлеров и банков (т.е. это не того размера предприятия, типа ООО «Вася Пупкин») только одну опенсорсную СХД — MySQL.
А все юзют Оракл и MS SQL и не жужжат про опенсорс.
А пока не видел ни одного. Может я не в тех ЦОДах бываю?
Не воспринимайте это как выпад против вас или продукта Ceph, просто некоторые вещи применимы не для всех. Вот если вы облачный провейдер, то наверно, для вас это будет интерестно. А если вы обычная компания, то вам, наверное, не стоит этого делать, потому что это нужно запустить это в эксплуатацию, поддерживать и не дай Бог восстанавливать.
А вот большие облачные провайдеры могут себе это позволить юзать.
Nexanta альтернатива ONTAP, так как ZFS использует часть кода WAFL и появилась, соответственно позже.
А ZFS в свою очередь был экспроприирован SAN/Oracle
Зато последний выплатил нетапу не малую суммы, но получил разрешение юзать его дальше, потому-что, к тому времени, новая кластерная версия WAFL уже шагнула далеко вперед
И посмотрите где Nexanta, а где флагманский продукт ONTAP:
Первый пытался занять нишу, в то время как ONTAP живет и здравствует.
Потому-что все версии ONTAP на всех платформах одинаковый код юзают.
Всё-равно будет доступно в агрегате столько, сколько куплено
В качестве дисков пробрасываются RDM или vmdk, внутри это видно как диски из которых собирается RAID0, поверх создается агрегат и вольюмы поверх агрегата.
Есть 90 дневная трал версия на 20ТБ
Конфигурация виртуальной машины и количество виртуальной памяти и ЦПУ увеличить можно, но в этом нет смысла потому что ONTAP будет использовать только то что ей нужно. С хутшими параметрами не будет работать
Система будет работать без рейд контроллера но нетап не тестировал такую конфигурацию и не знает будет ли это работать оптимально и будет ли работать вообще.
Если у вас будет какая-то инфа, пишите, мне самому будет интересно услышать «за и против».
К примеру Veeam 9 B&R. Не знаю всех деталей почему, но одини из аргументов звучал так:
Указанные максимальные параметры производительности с включённым дедупом и компрессией и максимальной набивкой дисков. Максимумы здесь.
Программы гарантирования скорости нет.
В то время как ONTAP заточен на случайный доступ небольшими блоками (Виртуализация/БД и др. приложения)
AVA заточена на последовательную запись/чтение для обеспечения высокой скорости линейной записи бэкапов.
В Backup режиме скорость чтения/записи
По CommVailt/TSM: не все заказчики могут себе позволить лить в публичное облако, плюс в AVA есть встроенная функция аппаратного онлайн дедупа/сжатия, шифрования и DR функционал в публичном/частном облаке. продукты TSM, CommVault не умеют принимать SnapMirror, так как это функция исключительно оборудования NetApp. Указанные продукты умеют управлять репликой SnapMirror между двумя хранилищами NetApp, в этом свете поддержка SnapMirror на стороне AVA будет весьма полезна: бекап будет литься с основного хранилища NetApp напрямую в AVA минуя собственно хост который бэкапируется и минуя Proxy-сервер, что позволит существенно ускорить процесс бэкапирования, в то время как софт резервного копирования будет только лишь управлять этим процессом.