Коллега приходит, а телефон с семью пропущенными лежит в кружке (или любой другой подходящей емкости), для первого раза в пустой. Как показала практика, очень дисциплинирует в плане оставления телефона с не выключенным звуком на рабочем месте.
На вкус и цвет все фломастеры IOPS разные. Для меня вообще всегда странно выглядит тест с 100% чтения. Вы где в жизни такие сервисы видели? Которые только читают и ничего не пишут. Или читают только блоком одного размера. А если читать блоком 64KiB, то 270k IOPS резко превратятся в тыкву? Это уже не говоря про то что отдельный диск, с возможностью потерять все, и диск в RAID это совершенно разные диски, в том числе по производительности. И сравнивать их в лоб некорректно. Кстати а Тошиба указала при каком количестве потоков и с какой latency один диск выдает 270k IOPS? А сможете взять 5 таких дисков и на одном сервере показать нам 1 миллион IOPS с разумным временем отклика хотя бы в синтетике?
По поводу чистки системного блока от пыли. Все решается визитом раз в полгода-год на ближайшую шиномонтажку с этим самым системником под мышкой. Дальше просите попользоваться сжатым воздухом. Обычно по цене подкачки колес (если шиномонтажка жадная), т.е. в 100 руб. можно уложиться. А дальше за 5 мнут выдуваете начисто всю пыль из корпуса сняв боковую крышку системника. Главное взять с собой карандаши или вязальные спицы (или что-то подобное), что бы заблокировать вращение всех вентиляторов в корпусе, перед началом процедуры. Иначе вентиляторы уйдут под замену, так как их подшипники не выдерживают вращения под таким потоком воздуха.
Ни какие другие способы не позволяют отчистить корпус настолько качественно и быстро (да в общем-то и не дорого, учитывая периодичность). Пылесосы, кисточки и тряпочки и рядом не валялись. И главное разбирать ничего не нужно.
Все относительно. В зависимости от каналов связи "рядом" может означать 100-200 км. Это те расстояния на которых возможна синхронная репликация при относительно нормальном времени отклика.
Active/active (не путать с двунаправленной асинхронной) и асинхронная репликация изначально вещи взаимоисключающие. При асинхронной репликации вторая площадка всегда passive и недоступна хостам при нормальном режиме работы (только если снапшот с нее делать и отдавать его хостам для бэкапа например). Да и просто банально вторая площадка всегда отстает от первичной площадки на некую дельту данных при асинхронной репликации.
Спасибо за статью. Вспомнил былое. Когда-то работал и оператором на экструдере и позже технологом на производстве с экструдерами. А теперь вот уже давно в IT :).
По простою экструдеров могу сказать, что основная боль это запуск и выход на качественную продукцию, который занимает до нескольких часов. А все это время сырье проходящее через экструдер идет на производство брака :(. Причем в зависимости от производственной мощности экструдера брак может измеряться и сотнями кг и тоннами. И это помимо непрямых потерь простоя производства.
Причем это можно сделать и на арендованных виртуалках например при необходимости, А их конвертировать и переносить должно быть попроще, да и структура и доступ пользователей не сломается.
Т.е. в случае выхода из строя контроллера на первой площадке, данные записанные на второй площадке буду с обоих контроллеров "пихаться" в живой контроллер на первой. Все верно? Или все таки все POD переедут на один контроллер на второй площадке?
Куда будет писать данные живой контроллер на первой площадке? В один контроллер на второй? Вообще в нормально режиме как выбирается контроллер, которому передать данные на удаленной площадке?
Сборка метро кластера возможна, если заказчик не хочет давать массивам выход в интернет и нет возможности подключить облачный Cloud Mediator?
Как отработает кластер split-brain, если обе площадки работают, но пропала связь с Cloud Mediator и оборвались каналы репликации?
Вы не ответили про другие более надежные способы репликации, которые вы хотели бы видеть или видели на СХД.
Про 40G и 100G согласен только отчасти. Тут еще вопрос в распространенности сетевого оборудования и готовности существующих каналов связи к таким подключениям.
Вы зря упираете на максимальную пропускную способность :). Для СХД важнее показатели по транзакционной нагрузке (IOPS) и времени отклика (ms). Но если уж вы хотите приравнять все к пропускной способности каналов, то попробуйте поделить например 2GB/s (гигабайта) на 8KB (килобайт). Получите вполне приличную цифру в IOPS, и это только для операций записи, которые нужно передавать на удаленный массив. Много вы видели даже средних инсталляций, где суммарная транзационная нагрузка c хостов превышает хотя бы 100к IOPS?
Так что на мой взгляд решение от Pure вполне претендует на свое место в сегменте компаний, которые доросли уже до двух площадок, но не доросли еще до дорогих энтерпрайзных решений.
Интересно как реализовано подключение контроллеров массивов между площадками. Сама схема и логика работы (контроллер1 площадка1 в контроллер1 площадка2 или как?). Что произойдет например, если отваляться линки репликации только от одного контроллера одного массива? Оба массива будут лететь на одном крыле котроллере или это как-то по другому отрабатывается.
Чисто в теории, на удаленную площадку передаются только операции write. В нормальной режиме работы я сомневаюсь, что у вас процент записи по потоку превысит значение в 50% от общего потока ввода\вывода. Ну и All Flash СХД обычно используются как первичный сторадж под большую транзакционную нагрузку, т.е. в принципе сомнительно, что вы сможете при этом забить по потоку даже 10G интерфейс.
И предложенный способ репликации на самом деле самое лучшее, что может быть на рынке с текущим уровнем развития технологий (по крайней мере из того как описаны принципы работы у Pure), да еще и предлагается вендором "бесплатно". Какой еще более надежный способ репликации вы бы хотели увидеть? :)
Ну и не надо забывать что метро-кластер не равно резервное копирование.
По ScaleIO интересно. Слышал, что есть инсталляции в России, но без конкретики. Можете рассказать что используете для межнодового взаимодействия в кластере? Ethernet 10G? Сами ноды самосбор или брендовые сервера? Сам кластер ScaleIO используете только под хранение или совмещаете роли и на серверах гипервизары тоже крутятся? Что используете из OS на нодах ScaleIO? Что можете сказать про надежность из опыта эксплуатации? Проблемы с недоступностью или потерей данных случались? Если не секрет, то насколько большой кластер сейчас у вас по количеству нод и по полезной емкости? Просто что бы представлять масштабы действа и на сколько все серьёзно :).
По второму случаю и проблеме ничего не понятно. Разве на уровне FC не было настроено зонирование? И сервер с основной площадки просто по идее не должен видеть порты массива на второй площадке, хоть таргеты они, хоть инициаторы? Да и в принципе, под репликацию обычно рекомендуются отдельно выделенные под это порты и отдельные зоны для этих портов между массивами. Без пересечений с вводом\выводом от хостов к массивам.
Если есть понимание, как у вас сервер увидел порты массива на удаленной площадке, то поясните пожалуйста.
А можно хотя бы одну картинку/фото, как выглядит ваша СХД в железе? Сколько юнитов занимает, насколько компоненты hot swap и т.п.? А то много текста, а дальше пусть работает воображение потенциальных клиентов?
Пообещайте налить в следующий раз горячий сладкий чай. :)
Коллега приходит, а телефон с семью пропущенными лежит в кружке (или любой другой подходящей емкости), для первого раза в пустой. Как показала практика, очень дисциплинирует в плане оставления телефона с не выключенным звуком на рабочем месте.
На вкус и цвет все
фломастерыIOPS разные. Для меня вообще всегда странно выглядит тест с 100% чтения. Вы где в жизни такие сервисы видели? Которые только читают и ничего не пишут. Или читают только блоком одного размера. А если читать блоком 64KiB, то 270k IOPS резко превратятся в тыкву? Это уже не говоря про то что отдельный диск, с возможностью потерять все, и диск в RAID это совершенно разные диски, в том числе по производительности. И сравнивать их в лоб некорректно. Кстати а Тошиба указала при каком количестве потоков и с какой latency один диск выдает 270k IOPS? А сможете взять 5 таких дисков и на одном сервере показать нам 1 миллион IOPS с разумным временем отклика хотя бы в синтетике?По поводу чистки системного блока от пыли. Все решается визитом раз в полгода-год на ближайшую шиномонтажку с этим самым системником под мышкой. Дальше просите попользоваться сжатым воздухом. Обычно по цене подкачки колес (если шиномонтажка жадная), т.е. в 100 руб. можно уложиться. А дальше за 5 мнут выдуваете начисто всю пыль из корпуса сняв боковую крышку системника. Главное взять с собой карандаши или вязальные спицы (или что-то подобное), что бы заблокировать вращение всех вентиляторов в корпусе, перед началом процедуры. Иначе вентиляторы уйдут под замену, так как их подшипники не выдерживают вращения под таким потоком воздуха.
Ни какие другие способы не позволяют отчистить корпус настолько качественно и быстро (да в общем-то и не дорого, учитывая периодичность). Пылесосы, кисточки и тряпочки и рядом не валялись. И главное разбирать ничего не нужно.
Все относительно. В зависимости от каналов связи "рядом" может означать 100-200 км. Это те расстояния на которых возможна синхронная репликация при относительно нормальном времени отклика.
Active/active (не путать с двунаправленной асинхронной) и асинхронная репликация изначально вещи взаимоисключающие. При асинхронной репликации вторая площадка всегда passive и недоступна хостам при нормальном режиме работы (только если снапшот с нее делать и отдавать его хостам для бэкапа например). Да и просто банально вторая площадка всегда отстает от первичной площадки на некую дельту данных при асинхронной репликации.
Себя же и поправлю. Правильнее называть не оператор, а машинист экструдера :). Звучит правда забавно.
Спасибо за статью. Вспомнил былое. Когда-то работал и оператором на экструдере и позже технологом на производстве с экструдерами. А теперь вот уже давно в IT :).
По простою экструдеров могу сказать, что основная боль это запуск и выход на качественную продукцию, который занимает до нескольких часов. А все это время сырье проходящее через экструдер идет на производство брака :(. Причем в зависимости от производственной мощности экструдера брак может измеряться и сотнями кг и тоннами. И это помимо непрямых потерь простоя производства.
Вот только знают об этом обычно только админы, работавшие с Unix подобными системами :).
Причем это можно сделать и на арендованных виртуалках например при необходимости, А их конвертировать и переносить должно быть попроще, да и структура и доступ пользователей не сломается.
Вот это ценное утонение :).
Т.е. в случае выхода из строя контроллера на первой площадке, данные записанные на второй площадке буду с обоих контроллеров "пихаться" в живой контроллер на первой. Все верно? Или все таки все POD переедут на один контроллер на второй площадке?
Куда будет писать данные живой контроллер на первой площадке? В один контроллер на второй? Вообще в нормально режиме как выбирается контроллер, которому передать данные на удаленной площадке?
Сборка метро кластера возможна, если заказчик не хочет давать массивам выход в интернет и нет возможности подключить облачный Cloud Mediator?
Как отработает кластер split-brain, если обе площадки работают, но пропала связь с Cloud Mediator и оборвались каналы репликации?
Вы не ответили про другие более надежные способы репликации, которые вы хотели бы видеть или видели на СХД.
Про 40G и 100G согласен только отчасти. Тут еще вопрос в распространенности сетевого оборудования и готовности существующих каналов связи к таким подключениям.
Вы зря упираете на максимальную пропускную способность :). Для СХД важнее показатели по транзакционной нагрузке (IOPS) и времени отклика (ms). Но если уж вы хотите приравнять все к пропускной способности каналов, то попробуйте поделить например 2GB/s (гигабайта) на 8KB (килобайт). Получите вполне приличную цифру в IOPS, и это только для операций записи, которые нужно передавать на удаленный массив. Много вы видели даже средних инсталляций, где суммарная транзационная нагрузка c хостов превышает хотя бы 100к IOPS?
Так что на мой взгляд решение от Pure вполне претендует на свое место в сегменте компаний, которые доросли уже до двух площадок, но не доросли еще до дорогих энтерпрайзных решений.
Интересно как реализовано подключение контроллеров массивов между площадками. Сама схема и логика работы (контроллер1 площадка1 в контроллер1 площадка2 или как?). Что произойдет например, если отваляться линки репликации только от одного контроллера одного массива? Оба массива будут лететь на одном
крылекотроллере или это как-то по другому отрабатывается.Чисто в теории, на удаленную площадку передаются только операции write. В нормальной режиме работы я сомневаюсь, что у вас процент записи по потоку превысит значение в 50% от общего потока ввода\вывода. Ну и All Flash СХД обычно используются как первичный сторадж под большую транзакционную нагрузку, т.е. в принципе сомнительно, что вы сможете при этом забить по потоку даже 10G интерфейс.
И предложенный способ репликации на самом деле самое лучшее, что может быть на рынке с текущим уровнем развития технологий (по крайней мере из того как описаны принципы работы у Pure), да еще и предлагается вендором "бесплатно". Какой еще более надежный способ репликации вы бы хотели увидеть? :)
Ну и не надо забывать что метро-кластер не равно резервное копирование.
Спасибо за ответ. Интересно будет почитать пост, когда подготовите. Буду ждать :).
По ScaleIO интересно. Слышал, что есть инсталляции в России, но без конкретики. Можете рассказать что используете для межнодового взаимодействия в кластере? Ethernet 10G? Сами ноды самосбор или брендовые сервера? Сам кластер ScaleIO используете только под хранение или совмещаете роли и на серверах гипервизары тоже крутятся? Что используете из OS на нодах ScaleIO? Что можете сказать про надежность из опыта эксплуатации? Проблемы с недоступностью или потерей данных случались? Если не секрет, то насколько большой кластер сейчас у вас по количеству нод и по полезной емкости? Просто что бы представлять масштабы действа и на сколько все серьёзно :).
А СХД я так подозреваю "массивы-скрипки"? До сих пор эксплуатируете или на что-то другое перешли?
По второму случаю и проблеме ничего не понятно. Разве на уровне FC не было настроено зонирование? И сервер с основной площадки просто по идее не должен видеть порты массива на второй площадке, хоть таргеты они, хоть инициаторы? Да и в принципе, под репликацию обычно рекомендуются отдельно выделенные под это порты и отдельные зоны для этих портов между массивами. Без пересечений с вводом\выводом от хостов к массивам.
Если есть понимание, как у вас сервер увидел порты массива на удаленной площадке, то поясните пожалуйста.
А можно хотя бы одну картинку/фото, как выглядит ваша СХД в железе? Сколько юнитов занимает, насколько компоненты hot swap и т.п.? А то много текста, а дальше пусть работает воображение потенциальных клиентов?