Альтернатива блочному iSCSI это FC и FCoE.
Есть еще варианты файловых протоколов NFS и CIFS (SMB), но так как у этих протоколов нет встроенного мультипасинга и балансировки нагрузки, этот недостаток им нужно компенсировать чем-то. Такой компенсацией являются LACP с EtherChannel или лучше LACP с Multi Chassis EtherChannel. Соответственно первый вариант с файловыми протоколами и прямым подключением реализовать не удастся, для этого понадобится не любой, а свич с вышеперечисленным функционалом, на котором нужно будет еще настроить этот функционал.
Потому что он хорош как для маленького ЦОД так и для большого. Для маленького не нужно покупать HBA адаптеры или специальные свичи. На начальном этапе можно задействовать обычные свичи. При росте с маленького до большого не меняется вся концепция, собственно об этом вся статья. Ну и производительность у iSCSI с 10GbE подключением ничем не хуже FC8, по крайней мере так у NetApp (у других производителей эта ситуация может быть другая). Благодаоя тому, что iSCSI не уступает по производительности и при этом живет поверх Ethernet, есть возможность клнсолидировать блочный трафик с другим трафиком на одном и том же сетевом оборудовании, таким образом есть возможность допрлнительно сэкономить. А приоритизация трафика позволит смешивать высокоприоритетный трафик с остальным без компромиса. И конечно же с NetApp FAS вы всегда вольны переключаться между iSCSI/FC/FCoE.
Универсального рецепта, конечно же нет. Каждый взвешивают интересующие именно его, «за» и «против».
Следующие возможности аппаратного ускорения работы сетевого адаптера (TOE NIC) могут снизить нагрузку на CPU хоста:
Receive Side Scaling (RSS)
TCP Chimney Offload
Jumbo Frames
Large Send Offload
Обратите внимание, что не все сетевые адаптеры с TOE поддерживают все перечисленные функции.
Аппаратные HBA адаптеры для iSCSI, к вышеперечисленному, берут обработку ещё и четвертого уровмя модели OSI, они собственно аппаратно обрабатывают сам протокол iSCSI.
В эру многопроцессорности и высоких скоростей CPU появляется большое множество вариантов сравнения. Так к примеру некоторые HBA адаптеры построены на базе обычного x86 CPU. Настройки, наличие или отсутствие каких-то функций, к примеру DCB или включение функции Jumbo Frames в Software и iSCSI HBA могут существенно влиять на результыты нагрузки CPU.
Другими словами проще взять и проверить нагрузку самому, так как в вашем случае с вашим оборудованием, разница между какими-то статистическими данными может оказаться существенная. Для этого вы можете восспользоваться утилитами по генерации нагрузки, к примеру IOMeter.
К примеру, на сервере с двумя quad-core Intel® Xeon® E5405 процессорами с частотой 2.0 GHz, 16 GB памяти и установленным
10GB адаптером (c TOE), можно достичь 750 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 15%. В случае увеличения размера блока (до 64 KB), утилизация CPU может достигать 26%.
10GB адаптером (c iSCSI HBA), можно достичь 750 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 1%.
адаптером 1 GbE (с TOE), можно достичь 120 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 2%.
адаптером 1 GbE (с выключенным TOE), можно достичь 120 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 3%.
адаптером 1 GbE (с iSCSI HBA), можно достичь 110 MB/s при оперировании 512 KB блоками данных (видео), утилизация CPU при этом достигает 1%.
Это вы про PFC IEEE 802.1Qbb что-ли?
Все-равно не пойму к чему тут именно iSCSI, с точно таким же успехом можно говорить про любой другой протокол работающий поверх Ethernet, к примеру CIFS (SMB), NFS и т.д.
Подскажите как EazyPhoto идентифицирует фотографию, по пути или по хэшу файла?
Если фотку взять и переместить в другую папку например, в веб форме она останиться и на том же месте/альбоме?
Тогда SPOS не ваш случай. SPOS предназначен для «некластерных» приложений.
Все описанные ограничения касаются SPOS. SnapProtect с данными лежащими на FAS работает со всеми этими приложениями.
Как и у любой технологии здесь есть свои ограничения, так что поинтересуйтесь вашим конкретным случаем с интегратором/дистрибютором или напрямую у нетапа. Обязательно посмотрите матрицу совместимости.
Если есть кластерные приложения, нужно либо перенести их на нетапп, и тогда SnapProtect сможет их бекапить.
Либо восспользоваться другим ПО, котрое может выполнять резервное копирование таких данных на нетап, к примеру Veeam 8, CommVault, Symantec, SyncSort и т.д.
У нетапа взгляд на вещи логичный: если у вас есть SnapProtect и FAS, то логично бизнес-критические приложения держать на FAS, для того чтобы выполнять резервное копирование при помощи Hardware-Assistant Snapshot. Hardware-Assistant Snapshot позволяет снимать резервные копии чаще и не нагружать хосты.
В моём следующем, за этим, посте про Архитектуру резервного копирования NetApp рассказано как на основе SnapProtect получить всё тоже самое на основе консистентного снепшота.
Т.е. SnapProtect/SnapManager не просто сделает консистентный снепшот виртуалки, но и базы данных которая в ней живёт. А дальше при помощи, к примеру RMAN'а (точно также как если бы это был класический бекап), без каких-либо промежуточных «выдираний» базы данных из виртуального диска восстановить эти данные в новое место: на новое железо с новой ОС. Или при помощи мастера SnapProtect/SnapManager.
В статье про парадигму резервного копирования нетап все комментарии здесь, если не оговорено иначе, идёт про нетап. И фраза «по большому счёту», тоже относится ТОЛЬКО к нетап.
Вы почему-то ошибочно подумали, что я пишу «про картину мира в целом», хотя я уже не в первый коммент пытаюсь вам донести, что не веду речи «за жизнь в целом», а конкретно только про NetApp FAS.
Ещё раз, всё ниже сказанное касается только NetApp FAS
Снепшот вынесенный на удалённую площадку, с точки зрения нетапа — полноценный бекап.
Локальный снепшот это тот же бекап, не защищающий от выхода из строя оборудования — защита выполнена на уровне отказоустойчивости и дублирования компонент СХД, RAID. Такой локальный снепшот это тот же бекап защищающий от логической ошибки но при этом с возможностью моментального восстановления с точки зрения NetApp.
Итак подрезюмировав:
Отреплицированный бекап будет восстанавливаться дольше, но он защищён от катастроф.
Локальный бекап не защищён от катастроф, защищет от выхода из строя некоторых компонент СХД (не всей СХД в целом), но может быть моментально восстановлен.
Так вот эти две вещи прекрастно дополняют друг друга и сосуществуют вместе.
Так вот дьявол кроется в деталях ;)
Нетап первый реализовал технологию снепшотинга и за 1993-2015=23 года развил и довел их до ума.
По поводу дезинформации, я нигде не писал «про снепшоты в общем», здесь конкретно речь про снепшоты NetApp и конкретно на системах FAS — посмотрите заглавие статьи.
Ещё как бекап. Я вам целую статью наваял, а вы снова за своё.
Чтобы классический бекап снять, а потом мочь его восстановить, он тоже должен быть консистентный.
А вопрос «проблемы с другим железом», описан в моём предыдущем коментарии.
Реализация деталей у разных вендоров разная на всех уровнях: на уровне архитектуры самой СХД, на уровне ОС, на уровне фич и патентов, на уровне рейда и т.д. И у каждого вендора видение свое как что реализовать. Так у нетапа локальный снепшот это бекап не защищающий от физического повреждения (защиту обеспечивает сама СХД рейдом, HA и т.д.). А отреплицированный снепшот это полноценный бекап с как это себе «видит» нетап.
У нетапа многие вещи «не стандартно» реализованы, вы просто наверное, не работали с нетапом, так сказать в продакшн, вот тогда бы вы поняли, что детали реализации не важны — важен результат.
И миеть локальный бекап который может быть восстановлен за одну минуту, на продакшн, это очень удобно. Потому что бухгалтерша чаще допускает ошибки, нежели происходит потом или пожар.
Это у нас уже полемика пошла.
1) я же сказал, полноценные бекапы — это снепшоты на удалённой системе.
2) восстановить можно на третий, четвертый и т.д. сайт (с нетапом)
3) Если используется OSSV или SPOS можно восстанавливать данные «не на нетап».
4) у SnapProtect есть такая штука позволяющая энд юзеру бекапить и восстанавливать свои данные из ноутбука (т.е. данные живущие не на нетапе), называется Web Console.
А по поводу «отдельности бекапов», то в таком случае не вижу большой разницы между отдельной ленточной кассетой со сжатым бекапом и снепшотом.
Снепшот это полноценная полная файловая система на момент как она была зафиксирована. А если вы намекаете на то, что снепшоты могут как-то повредиться, то во-первых есть механизм проверки чексумм и восстановления при помощи RAID (чего нет у ленточных кассет), а во-вторых мне лично не известны такие случаи.
По большому счёту локальные снепшоты это полноценные бекапы, которые не защищают от физического повреждения СХД.
Тем не мение они прекрастно справляются с восстановлением нечаянно изменённых/удалённых данных, к примеру пользователем или вирусом — т.е. от логической ошибки, логического повреждения.
А чтобы защититься, в том числе, и от физического повреждения, нужно эти снепшоты выносить на другую площадку. Так вот на удалённой площадке те же самые снепшоты уже самые полноценные бекапы.
Есть еще варианты файловых протоколов NFS и CIFS (SMB), но так как у этих протоколов нет встроенного мультипасинга и балансировки нагрузки, этот недостаток им нужно компенсировать чем-то. Такой компенсацией являются LACP с EtherChannel или лучше LACP с Multi Chassis EtherChannel. Соответственно первый вариант с файловыми протоколами и прямым подключением реализовать не удастся, для этого понадобится не любой, а свич с вышеперечисленным функционалом, на котором нужно будет еще настроить этот функционал.
Универсального рецепта, конечно же нет. Каждый взвешивают интересующие именно его, «за» и «против».
Следующие возможности аппаратного ускорения работы сетевого адаптера (TOE NIC) могут снизить нагрузку на CPU хоста:
Обратите внимание, что не все сетевые адаптеры с TOE поддерживают все перечисленные функции.
Аппаратные HBA адаптеры для iSCSI, к вышеперечисленному, берут обработку ещё и четвертого уровмя модели OSI, они собственно аппаратно обрабатывают сам протокол iSCSI.
В эру многопроцессорности и высоких скоростей CPU появляется большое множество вариантов сравнения. Так к примеру некоторые HBA адаптеры построены на базе обычного x86 CPU. Настройки, наличие или отсутствие каких-то функций, к примеру DCB или включение функции Jumbo Frames в Software и iSCSI HBA могут существенно влиять на результыты нагрузки CPU.
Другими словами проще взять и проверить нагрузку самому, так как в вашем случае с вашим оборудованием, разница между какими-то статистическими данными может оказаться существенная. Для этого вы можете восспользоваться утилитами по генерации нагрузки, к примеру IOMeter.
К примеру, на сервере с двумя quad-core Intel® Xeon® E5405 процессорами с частотой 2.0 GHz, 16 GB памяти и установленным
Можете описать что это такое и как это помогает iSCSI?
Все-равно не пойму к чему тут именно iSCSI, с точно таким же успехом можно говорить про любой другой протокол работающий поверх Ethernet, к примеру CIFS (SMB), NFS и т.д.
Что значит поддержка iSCSI? Ведь iSCSI работает поверх TCP, а его все Ethernet коммутаторы пропускают :)
Если фотку взять и переместить в другую папку например, в веб форме она останиться и на том же месте/альбоме?
Все описанные ограничения касаются SPOS. SnapProtect с данными лежащими на FAS работает со всеми этими приложениями.
Как и у любой технологии здесь есть свои ограничения, так что поинтересуйтесь вашим конкретным случаем с интегратором/дистрибютором или напрямую у нетапа. Обязательно посмотрите матрицу совместимости.
Если есть кластерные приложения, нужно либо перенести их на нетапп, и тогда SnapProtect сможет их бекапить.
Либо восспользоваться другим ПО, котрое может выполнять резервное копирование таких данных на нетап, к примеру Veeam 8, CommVault, Symantec, SyncSort и т.д.
У нетапа взгляд на вещи логичный: если у вас есть SnapProtect и FAS, то логично бизнес-критические приложения держать на FAS, для того чтобы выполнять резервное копирование при помощи Hardware-Assistant Snapshot. Hardware-Assistant Snapshot позволяет снимать резервные копии чаще и не нагружать хосты.
Т.е. SnapProtect/SnapManager не просто сделает консистентный снепшот виртуалки, но и базы данных которая в ней живёт. А дальше при помощи, к примеру RMAN'а (точно также как если бы это был класический бекап), без каких-либо промежуточных «выдираний» базы данных из виртуального диска восстановить эти данные в новое место: на новое железо с новой ОС. Или при помощи мастера SnapProtect/SnapManager.
И вот именно это, я и называю полемикой.
Ещё раз, всё ниже сказанное касается только NetApp FAS
Итак подрезюмировав:
Так вот эти две вещи прекрастно дополняют друг друга и сосуществуют вместе.
Нетап первый реализовал технологию снепшотинга и за 1993-2015=23 года развил и довел их до ума.
По поводу дезинформации, я нигде не писал «про снепшоты в общем», здесь конкретно речь про снепшоты NetApp и конкретно на системах FAS — посмотрите заглавие статьи.
Чтобы классический бекап снять, а потом мочь его восстановить, он тоже должен быть консистентный.
А вопрос «проблемы с другим железом», описан в моём предыдущем коментарии.
Реализация деталей у разных вендоров разная на всех уровнях: на уровне архитектуры самой СХД, на уровне ОС, на уровне фич и патентов, на уровне рейда и т.д. И у каждого вендора видение свое как что реализовать. Так у нетапа локальный снепшот это бекап не защищающий от физического повреждения (защиту обеспечивает сама СХД рейдом, HA и т.д.). А отреплицированный снепшот это полноценный бекап с как это себе «видит» нетап.
У нетапа многие вещи «не стандартно» реализованы, вы просто наверное, не работали с нетапом, так сказать в продакшн, вот тогда бы вы поняли, что детали реализации не важны — важен результат.
И миеть локальный бекап который может быть восстановлен за одну минуту, на продакшн, это очень удобно. Потому что бухгалтерша чаще допускает ошибки, нежели происходит потом или пожар.
1) я же сказал, полноценные бекапы — это снепшоты на удалённой системе.
2) восстановить можно на третий, четвертый и т.д. сайт (с нетапом)
3) Если используется OSSV или SPOS можно восстанавливать данные «не на нетап».
4) у SnapProtect есть такая штука позволяющая энд юзеру бекапить и восстанавливать свои данные из ноутбука (т.е. данные живущие не на нетапе), называется Web Console.
А по поводу «отдельности бекапов», то в таком случае не вижу большой разницы между отдельной ленточной кассетой со сжатым бекапом и снепшотом.
Снепшот это полноценная полная файловая система на момент как она была зафиксирована. А если вы намекаете на то, что снепшоты могут как-то повредиться, то во-первых есть механизм проверки чексумм и восстановления при помощи RAID (чего нет у ленточных кассет), а во-вторых мне лично не известны такие случаи.
Тем не мение они прекрастно справляются с восстановлением нечаянно изменённых/удалённых данных, к примеру пользователем или вирусом — т.е. от логической ошибки, логического повреждения.
А чтобы защититься, в том числе, и от физического повреждения, нужно эти снепшоты выносить на другую площадку. Так вот на удалённой площадке те же самые снепшоты уже самые полноценные бекапы.