Кстати хотел спросить, а зачем вам «всё знать» про вендора, которого вы упорно и всегда критикуете буквально в любой статье где речь заходит за NetApp, учитывая что он такой плохой?
Я так понимаю вы в интеграторе работаете и далеко не NetApp занимаетесь, правильно я понял?
У меня такое ощущение что «всё знать про NetApp» связано, особенно в маркетинговом плане, не просто с жаждой знаний.
Я плачу. Просто плачу катаясь под столом. Вы ж вроде в Англии живёте. Читать на ангицком должны уметь. А ещё меня учить хотели.
Всё уже, прочитали, поняли, о чём в той статье говорилось? Что там про Cloud Volumes Service (Читай NetApp AFF), что это не исключительно речь про бэкапы, они как бы тоже (also) есть. И что в 8 новых регионах этот сервис с «устаревшими технологиями» NetApp AFF открыли. не с нутаниксом почему-то…
Ах да. Буржуи. Заговор… и не забываем добавить, то что NetApp ничего не спасёт.
Ой, так напишите статью на хабре про архитектуру и как в вашем нутаниксе операции записи на соседние ноды телепортируются без использования сети. И как они не занимают в 3 раза больше ёмкости с фактором репликации 3.
Если мы говорим уже за SF, то там тоже, на подобии как в Nutanix есть репликация между нодами по сети. Ключевое слово тоже, так что не нужно тут пытаться опять песни петь про локальные диски и православные локальные записи. Вы как-то внезапно на SF переключились, хотя говорили мы про ONTAP & AFF и NoSQL, ну да ладно.
Да, в NetApp HCI/SF нужно по сути минимум две ноды SF и две ноды серверов, итого 4ре, а 10 версии прошивки нужно минимум 4 ноды SF. Я об этом честно пишу. Но опять таки уменьшаем/увеличиваем количество нод, что будет с нутаниксом? Потеряем пространство если нужно уменьшить компьютин, если нужно увеличить компьютинг — автоматом добавим пространство, нужно оно или нет, а добавить обязан. В архитектуре NetApp HCI компьютинг и пространство могут уменьшаться/расти независимо.
Ох уж этот режим защиты нутаникс. Всех порву. Все дураки. Один я дартаньян потому что читал биболию нутаникс.
EC-X это конечно классная штука. Сначала делаем replication factor 3, магко говоря охреневаем от оверхэдов как по пространству, так и по сети. А потом такие, «а давайте ка мы Eresure Coding по сети на продуктив натянем» (С)? Экономия! Только перфоменс гуляет лесом. Потому что это обратная строна медали EC. Когда у тебя есть опции, это говорит, что технология имеет недостатки, где выбор и принятие между несколькими обоими плохими решениями перелаживаются на плечи заказчика. Хотите безопасность — ставьте репликацию 3 (и охреневайте от оверхэдов), хотите сэкономитть, ставьте 2, хотите сильнее сэкономить, ставьте EC (и охреневайте от performance impact)! И каждый из этих вариантов со смоими проблемами.
Сделал себе проблему, а потом героически решил, точнее дал ложный выбор. А потом ещё сказать, а у вас в SF нет такой штуки как EC! Круто.
Я вам технически уже выложил выше. И про репликацию по сети и про в 3 раза больше ёмкости и про архитектурные ограничения.
И читайте внимательнее там есть запятая и слово «and» в заголовке.
Чтобы вы били в курсе, NetApp Cloud Volumes Service for AWS построены на «устаревших» NetApp AFF, в октябре добавили 8 новых регионов.
Да я опредилился. И повторяю вам еще раз, вы сами начали разговор за консистентность в базах данных и про то что его «можно включить если нужно», я его и продолжил. И этот трэд он был конкретно в тему про гиперскейлеров которые юзают файловые системы и баз данных с cогласованностью в конечном счёте (когда нибудь, может быть) и не юзают стореджи.
Я вам здесь и говорю не за ваш нутаникс, а за эти вот NoSQL базы данных. А вы всё со своим режимом защиты нутаникса, на свой счёт принимаете. Читайте внимательнее и отключите свой режим защиты нутаникса.
Это не ерунда, а правда жизни. Когда Вы включаете консистентность в моднго ДБ палает перфоменс в 5 раз. Когда отключаете, выростает. Это плата за консистентность и я говорю что эта плата она всегда есть. Я сейчас про БД, не про ваш нутаникс, если что.
Ох уж этот NetApp со своими устаревшими технологиями!
Ох уж эти AWS, Azure, Google Cloud, IBM Cloud, Rackspace (и скоро ждите еще одного крупного играка), все хотят напродавать своим заказчикам этот поганый и устаревший NetApp своим заказчикам, а сами то посмотрите, сами то его не используют!
Всё строют и строют свои датацентры, расширяют покрытие со своими сутаревшими технологиями.
Это никак иначе как глобальный сговор буржуев против православного нутаникса!
Предлагаю выключить режим всезнайки,- плохо получается.
Необходимость реплицировать данные между нодами и есть лимит в данной архитектуре. По этому на практике лимит будет, точнее он есть.
А что такое устаревшая технология в данном случае и что есть новая технология? Новая это там где нужно в 3 раза больше накладных расходов по ёмкости и там где в два раза больше накладных расходов на cross-talsk между нодами кластера при записи? Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?
В то время как в древнем ONTAP все данные пишуться на ноду которая владеет этим вольюмом и только при аварии переключается и соответственно не жрёт ни рисурсов соседного контроллера ни дополнительных расходов на сеть?
И что значит не поможет, вы в будущем были, у вас машина времени? Давайте дождёмся этого будущего и посмотрим, а не будем выдавать желаемое за действительное. Я к примеру, свои два предсказания сделал потому что уже 7 лет этими устройствами занимаюсь и знаю как оно устроено и куда движется, и громких заявлений типа «нутаникс умрёт и ничто ему не поможет» не делаю.
О боже. У вас какой-то режим защиты нутаникса включился неадекватный.
Никто и не говорил про ваш нутаникс. Понятное дело что в Нутаниксе он включён всегда, иначе быть не может.
совершенно спокойно может работать в CAp режиме когда требуется.
Я говорю без привязки к Nutanix, если в NoSQL BD такой как MongoDB (подозреваю что в Касандре будет аналогичная картина) включить режим консистентности, то там просядет производительность в 5 раз по сравнению с той же самой БД, только с eventual consistency. Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.
Ну при чём же здесь S3. Он преспокойно себе живет и работает на комодити оборудовании. Иногда работает, иногда не работает. Но опять таки постановка задачи у него «дешевое» и надёжное хранилище данных (про доступность этих данных умалчиваем). Которое кстати под задачи виртуальных машин и задачи баз данных использовать не возможно. Потому что протокол в основном заточен на то чтобы туда один раз записали и много раз читали. Или подождали пару часиков и прочитали ;)
Рома, ну ты сам прекрастно видишь, что все бегают с этими лозунгами «локальные диски быстрее», как обычно оставив в стороне «технические детали». Просто пора уже придумывать новые лозунги, эти устарели ;)
Таки да. Это маркетинг. Картинки, слайды, собранная и пережёванная информация. Это не техническая документация.
Техническая документация без слайдиков и не из 100 страниц картинок, а 300 страниц сухого технического текста который рассказывает всё как есть без предвзятости, прикрас и маркетинга здесь
Боже, на кой чёрт вам этот документ? Что вам не хватает в характеристиках HWU?
Я вам еще раз говорю, что я просто уверен в том, что у нутаникса тоже есть такой же аналог fieldportal, к которому у вас тоже никто доступа нет.
У этих компаний другая постановка задачи, которая выливается в то, как у них построена внутренняя архитектура под эту задачу и как результат что они для этой задачи используют. И это отнюдь не связано с тем, что shared-nothing архитектура априори лучше и быстрее. Объясню. У этих компаний контент распределяется по их кластерным файловым системам или БД с задержкой, это называется eventual consistency, которую на практике им невозможно достичь. На пальцах: из-за eventual consistency разным пользователям в разных регионах, в поиске гугла/ФБ могут «не доползать» некоторые новые статьи. Но какая разница для пользователя, если он недополучит пару новых статей и вместо них будут другие тоже релевантные для поиска, но просто немного более старые статьи, если у него результат поиска и так состоит из релевантных 10 страниц, на каждой по 10 ссылок. Пользователь просто не заменит этой разницы или она будет не существенна и для бизнеса ФБ/Гугл это приемлемо и не критично.
Благодаря принципу eventual consistency, они могут не покупать промышленные системы хранения под описанные выше задачи, а использовать свою кластерную ФС/БД вместо этого, потому что им это может позволить сама постановка задачи. И не забывайте про армию программистов, которые постоянно допиливают эти алгоритмы.
При том в инфраструктуре с приложениями, к примеру виртуальными машинами, вы не можете себе позволить eventual consistency, это просто не из того мира функционал. Если у вас умирает один сервер с кучей виртуалок, а на второй сервер ещё не успели докатиться самые последние данные, у вас будет куча повреждённых виртуалок. Другими словами вам необходимо синхронно реплицировать данные и ярким примером тому является Nutanix.
А теперь давайте про гиперскейлеров. Оборудование (или софт) NetApp есть в таких гиперскейлерах как Azure, Amazon AWS, Google Cloud, Rackspace, IBM Cloud (и на этом список не заканчивается на самом деле) и доступно как сервис для конечных потребителей. Почему? Да потому что есть много задач в которых shared storage показывает необходим, имеет много функционала и показывает себя с очень хорошей стороны. Иначе бы NetApp не появился у них в ЦОДах.
Например — «скорость записей плюс минус в лучшем случае равносильна тому» — не в лучшем, а в худшем
Нет, таки в лучшем уважаемый коллега. Почему? Всё просто: replication factor 3. Нужно реплику не на один, а на два внешних сервера слать, да, они шлются параллельно, но разные сервера по-разному нагружены, мало того, что там «сторедж функция», так там ещё и компьютинг крутится, поэтому один из этих серверов может быть более занят чем другой. Плюс получается по сети в два раза больше внутреннего трафика бегает и вместо 2 нод так у вас еще и третья задействована. Это всё дополнительные накладные расходы. Именно поэтому применено выражение «в лучшем случае».
А вот в случае replication factor 2, то будет ровно тоже самое, как если бы система была подключена по сети откинуть влияние нагрузки серверов задачами от виртуальных машин. Эти нюансы вылазят именно из-за shared-nothing архитектуры и никуда от них ни деться. Это ни плохо и ни хорошо, они просто есть и про это нужно знать.
И вообще я Nutanix обидеть не хотел, заслуженная и уважаемая HCI архитектура. Но нужно расставить всё по своим местам, потому что даже при наличии «Библии Nutanix», всё равно некоторые инженеры думают, что записи пишутся исключительно локально, чего архитектура себе позволить не может при всём желании, далее делая из этого не правильные умозаключения, что говорит о том, как обычно техническую документацию никто не читает, а просто «борются на словах» не верными, маркетинговыми идеями.
Я так понимаю вы в интеграторе работаете и далеко не NetApp занимаетесь, правильно я понял?
У меня такое ощущение что «всё знать про NetApp» связано, особенно в маркетинговом плане, не просто с жаждой знаний.
Всё уже, прочитали, поняли, о чём в той статье говорилось? Что там про Cloud Volumes Service (Читай NetApp AFF), что это не исключительно речь про бэкапы, они как бы тоже (also) есть. И что в 8 новых регионах этот сервис с «устаревшими технологиями» NetApp AFF открыли. не с нутаниксом почему-то…
Ах да. Буржуи. Заговор… и не забываем добавить, то что NetApp ничего не спасёт.
Ой, как мне нравится как вы в каждом своём посте методично не забываете писать про Fake HCI. Жалко в Хабре хэштегов нет в комментариях…
А можно вас попросить в каждом своём комментарии к этой статье ставить хэштег #FHCI, мне так веселее будет?
Да, в NetApp HCI/SF нужно по сути минимум две ноды SF и две ноды серверов, итого 4ре, а 10 версии прошивки нужно минимум 4 ноды SF. Я об этом честно пишу. Но опять таки уменьшаем/увеличиваем количество нод, что будет с нутаниксом? Потеряем пространство если нужно уменьшить компьютин, если нужно увеличить компьютинг — автоматом добавим пространство, нужно оно или нет, а добавить обязан. В архитектуре NetApp HCI компьютинг и пространство могут уменьшаться/расти независимо.
Ох уж этот режим защиты нутаникс. Всех порву. Все дураки. Один я дартаньян потому что читал биболию нутаникс.
EC-X это конечно классная штука. Сначала делаем replication factor 3, магко говоря охреневаем от оверхэдов как по пространству, так и по сети. А потом такие, «а давайте ка мы Eresure Coding по сети на продуктив натянем» (С)? Экономия! Только перфоменс гуляет лесом. Потому что это обратная строна медали EC. Когда у тебя есть опции, это говорит, что технология имеет недостатки, где выбор и принятие между несколькими обоими плохими решениями перелаживаются на плечи заказчика. Хотите безопасность — ставьте репликацию 3 (и охреневайте от оверхэдов), хотите сэкономитть, ставьте 2, хотите сильнее сэкономить, ставьте EC (и охреневайте от performance impact)! И каждый из этих вариантов со смоими проблемами.
Сделал себе проблему, а потом героически решил, точнее дал ложный выбор. А потом ещё сказать, а у вас в SF нет такой штуки как EC! Круто.
И читайте внимательнее там есть запятая и слово «and» в заголовке.
Чтобы вы били в курсе, NetApp Cloud Volumes Service for AWS построены на «устаревших» NetApp AFF, в октябре добавили 8 новых регионов.
Я вам здесь и говорю не за ваш нутаникс, а за эти вот NoSQL базы данных. А вы всё со своим режимом защиты нутаникса, на свой счёт принимаете. Читайте внимательнее и отключите свой режим защиты нутаникса.
Это не ерунда, а правда жизни. Когда Вы включаете консистентность в моднго ДБ палает перфоменс в 5 раз. Когда отключаете, выростает. Это плата за консистентность и я говорю что эта плата она всегда есть. Я сейчас про БД, не про ваш нутаникс, если что.
Ох уж эти AWS, Azure, Google Cloud, IBM Cloud, Rackspace (и скоро ждите еще одного крупного играка), все хотят напродавать своим заказчикам этот поганый и устаревший NetApp своим заказчикам, а сами то посмотрите, сами то его не используют!
Всё строют и строют свои датацентры, расширяют покрытие со своими сутаревшими технологиями.
Это никак иначе как глобальный сговор буржуев против православного нутаникса!
Предлагаю выключить режим всезнайки,- плохо получается.
А что такое устаревшая технология в данном случае и что есть новая технология? Новая это там где нужно в 3 раза больше накладных расходов по ёмкости и там где в два раза больше накладных расходов на cross-talsk между нодами кластера при записи? Или новая это где нужно занимать ресурсы по памяти и CPU двух дополнительных серверов, которые можно было бы использовать под виртуалки?
В то время как в древнем ONTAP все данные пишуться на ноду которая владеет этим вольюмом и только при аварии переключается и соответственно не жрёт ни рисурсов соседного контроллера ни дополнительных расходов на сеть?
И что значит не поможет, вы в будущем были, у вас машина времени? Давайте дождёмся этого будущего и посмотрим, а не будем выдавать желаемое за действительное. Я к примеру, свои два предсказания сделал потому что уже 7 лет этими устройствами занимаюсь и знаю как оно устроено и куда движется, и громких заявлений типа «нутаникс умрёт и ничто ему не поможет» не делаю.
Никто и не говорил про ваш нутаникс. Понятное дело что в Нутаниксе он включён всегда, иначе быть не может.
Я говорю без привязки к Nutanix, если в NoSQL BD такой как MongoDB (подозреваю что в Касандре будет аналогичная картина) включить режим консистентности, то там просядет производительность в 5 раз по сравнению с той же самой БД, только с eventual consistency. Так что всегда когда у вас есть выбор что-то включать «если требуется», это значит что вы что-то взамен потеряете, в данном случае потеряете перфоменс БД.
Собственно вот вы сами и пришли к тому, что я сказал, что Nutanix интерестен своей внутренней экосистемой, а не устройством стореджа.
PS. Эта фраза больше не Женина, а моя.
Техническая документация без слайдиков и не из 100 страниц картинок, а 300 страниц сухого технического текста который рассказывает всё как есть без предвзятости, прикрас и маркетинга здесь
docs.netapp.com/ontap-9
docs.netapp.com/ontap-9
Я вам еще раз говорю, что я просто уверен в том, что у нутаникса тоже есть такой же аналог fieldportal, к которому у вас тоже никто доступа нет.
Просто вы про fieldportal знаете.
У этих компаний другая постановка задачи, которая выливается в то, как у них построена внутренняя архитектура под эту задачу и как результат что они для этой задачи используют. И это отнюдь не связано с тем, что shared-nothing архитектура априори лучше и быстрее. Объясню. У этих компаний контент распределяется по их кластерным файловым системам или БД с задержкой, это называется eventual consistency, которую на практике им невозможно достичь. На пальцах: из-за eventual consistency разным пользователям в разных регионах, в поиске гугла/ФБ могут «не доползать» некоторые новые статьи. Но какая разница для пользователя, если он недополучит пару новых статей и вместо них будут другие тоже релевантные для поиска, но просто немного более старые статьи, если у него результат поиска и так состоит из релевантных 10 страниц, на каждой по 10 ссылок. Пользователь просто не заменит этой разницы или она будет не существенна и для бизнеса ФБ/Гугл это приемлемо и не критично.
Благодаря принципу eventual consistency, они могут не покупать промышленные системы хранения под описанные выше задачи, а использовать свою кластерную ФС/БД вместо этого, потому что им это может позволить сама постановка задачи. И не забывайте про армию программистов, которые постоянно допиливают эти алгоритмы.
При том в инфраструктуре с приложениями, к примеру виртуальными машинами, вы не можете себе позволить eventual consistency, это просто не из того мира функционал. Если у вас умирает один сервер с кучей виртуалок, а на второй сервер ещё не успели докатиться самые последние данные, у вас будет куча повреждённых виртуалок. Другими словами вам необходимо синхронно реплицировать данные и ярким примером тому является Nutanix.
А теперь давайте про гиперскейлеров. Оборудование (или софт) NetApp есть в таких гиперскейлерах как Azure, Amazon AWS, Google Cloud, Rackspace, IBM Cloud (и на этом список не заканчивается на самом деле) и доступно как сервис для конечных потребителей. Почему? Да потому что есть много задач в которых shared storage показывает необходим, имеет много функционала и показывает себя с очень хорошей стороны. Иначе бы NetApp не появился у них в ЦОДах.
Нет, таки в лучшем уважаемый коллега. Почему? Всё просто: replication factor 3. Нужно реплику не на один, а на два внешних сервера слать, да, они шлются параллельно, но разные сервера по-разному нагружены, мало того, что там «сторедж функция», так там ещё и компьютинг крутится, поэтому один из этих серверов может быть более занят чем другой. Плюс получается по сети в два раза больше внутреннего трафика бегает и вместо 2 нод так у вас еще и третья задействована. Это всё дополнительные накладные расходы. Именно поэтому применено выражение «в лучшем случае».
А вот в случае replication factor 2, то будет ровно тоже самое, как если бы система была подключена по сети откинуть влияние нагрузки серверов задачами от виртуальных машин. Эти нюансы вылазят именно из-за shared-nothing архитектуры и никуда от них ни деться. Это ни плохо и ни хорошо, они просто есть и про это нужно знать.
И вообще я Nutanix обидеть не хотел, заслуженная и уважаемая HCI архитектура. Но нужно расставить всё по своим местам, потому что даже при наличии «Библии Nutanix», всё равно некоторые инженеры думают, что записи пишутся исключительно локально, чего архитектура себе позволить не может при всём желании, далее делая из этого не правильные умозаключения, что говорит о том, как обычно техническую документацию никто не читает, а просто «борются на словах» не верными, маркетинговыми идеями.