Купить СХД All-Flash (Флеш-массивы хранения данных)
Компания ИТЦ-М предлагает вам купить All-Flash Storage ведущих производителей: NetApp, Dell EMC, Lenovo и Huawei.
В дополнение к массивам хранения мы поставляем такие компоненты, как жесткие диски, оперативную память, контроллеры, блоки питания и дополнительные вентиляторы. Поможем с настройкой и внедрением СХД в ИТ-инфраструктуру вашей компании.
Флеш-массивы, содержащие твердотельные накопители (SSD) или другие формы флеш-памяти, обеспечивают хранение больших объемов данных с высокими, предсказуемыми характеристиками производительности. При значительном увеличении количества IOPS и пропускной способности они обладают меньшей задержкой, одновременно увеличивая эффективную емкость системы за счет встроенного сжатия и дедупликации. Важно понимать, как это работает, чтобы понять, смогут ли приложения в вашем центре обработки данных получить максимальную отдачу от all-flash системы хранения.
Некоторым приложениям требуется IOPS, другим — низкая задержка, а некоторым — высокая пропускная способность. Например, виртуализация серверов и приложения VDI обычно больше всего подвержены влиянию IOPS, высокопроизводительные вычисления и базы данных чувствительны к задержкам, а видеосистемам требуется высокая пропускная способность. Возможность охарактеризовать ваши приложения и их требования будет иметь большое значение при выборе новой системы хранения AFA (All Flash Array).
Флеш-массивы хранения данных (All-flash storage)
- All-flash СХД обеспечивают более высокую производительность, чем гибридные решения для хранения данных в средах с высоким уровнем транзакций и приложениях для анализа данных, благодаря различию в производительности твердотельных и шпиндельных накопителей.
- Ресурсы системы All-flash хранения данных можно эффективно использовать без снижения производительности.
- Первоначальные капитальные затраты на гигабайт выше у All-flash массива, по сравнению с гибридным.
- Плотность хранения данных All-flash массива для некоторых систем ниже.
Приложения для тестирования и сравнительного анализа, будь то только программные продукты или оборудование, могут помочь в поиске проблем с вашими текущими системами хранения данных, а также позволят вам понять, может ли система AFA справиться с нагрузкой. Имейте в виду, что вы не можете устранить все «узкие места», а только переместить их. Повышение производительности одной части системы приведет к выявлению следующего слабого места.
Приложения, которым требуется больше операций ввода-вывода в секунду.
Системы, выполняющие множество параллельных операций, как правило, требуют большого количества IOPS. К ним относятся виртуализация серверов и VDI, а также системы баз данных с большим количеством одновременных пользователей, от поисковых систем, таких как Google, до приложений электронной коммерции, таких как Amazon.
Хотя многие поставщики флеш-массивов заявляют, что их продукты могут выполнять миллион или более операций ввода-вывода в секунду, эти цифры трудно достичь в реальном мире. В то время как тестовое приложение может генерировать миллионы небольших (2 КБ) запросов для получения большего числа, реальные приложения, как правило, используют запросы большего размера (от 100 КБ до мегабайт).
Это затрудняет тестирование приложения и настройку испытательного стенда. Одна система SAN All-Flash с парой серверов просто не справится даже с подключениями 10 Гбайт и выше. Иногда лучшее решение — попросить поставщика предоставить контакты клиентов, которые уже внедрили систему, которая использует те же приложения, что и ваша организация, и поговорить с менеджерами центров обработки данных о проблемах, которые они обнаружили при внедрении хранилища AFA в среде, аналогичной вашей.
Программы, на которые влияет задержка.
Приложения, которые обрабатывают стек, передавая данные между узлами в кластере, особенно чувствительны к задержкам. Поскольку части приложения ожидают данных из предыдущей части, любые задержки при обработке или передаче данных могут привести к очередным задержкам. Высокопроизводительные вычислительные системы, кластерные базы данных, а также приложения, работающие в режиме реального времени и потоковые приложения — все они чувствительны к задержкам. При тестировании средняя или совокупная задержка является более информативной, чем минимальная, но также важно учитывать максимальные задержки.
Приложения с высокой пропускной способностью.
Приложения, которые перемещают большие объемы данных, требуют высокой пропускной способности. Эти приложения включают обработку видео для специальных эффектов, аналитику данных с большими наборами данных, например сейсмический анализ и интеллектуальный анализ данных. Все они зависят от совместного использования и обработки объемов данных от сотен гигабайт до петабайт. Возможность перемещения данных имеет решающее значение и часто требует больших каналов (от 10 Гбит/с до 100 Гбит с, Fibre Channel 16 или 32 Гбит/с) и эффективной обработки данных на уровне сетевого стека, а также дедупликации и сжатия передаваемых данных через LAN или WAN соединения.
Как и в случае с предыдущими параметрами, существуют проблемы и с пропускной способностью, которые могут быть не очевидны. Например, переход с 1 Гбит/с на 10-гигабитное соединение Ethernet обеспечит более высокую пропускную способность, но может также увеличить загрузку сервера в 10 раз и более. Это может привести к тому, что сервер, работающий с загрузкой 25%, будет работать с 50% загрузкой только для доступа к данным, что может вызвать сбои при скачках нагрузки в сети.
В качестве аргумента в пользу флеш-массивов хранения данных.
Обоснование перехода на AFA-хранилище начинается со сбора достаточного количества данных, чтобы можно было сказать не только «сеть работает медленно». Инструменты для сбора данных варьируются от функций ведения журналов, встроенных в Microsoft Systems Management Server или System Center Configuration Manager, или VMware vCenter, до специализированных инструментов, таких как SolarWinds Storage Manager. Эти инструменты помогают точно определить узкие места и охарактеризовать производительность систем хранения данных. Они также анализирую исторические данные и могут показывать, например, что система растет со скоростью, которая будет вызывать проблемы через шесть месяцев или через год. Эти данные позволяют вам проактивно создавать новый уровень хранения, справляясь с ростом данных, прежде чем он начнет влиять на производительность приложений.
Многоуровневые приложения сложны, данные между ними передаются множеством разных серверов, поэтому простое добавление производительного оборудования для медленного приложения может вообще не помочь. Необходимо изолировать реальные проблемы, найти первопричины, а затем протестировать предлагаемое решение, прежде чем что-либо обновлять.
