Многие помнят публикацию о «Рэйдикс» на Хабре «Как разработчики сидели в Петербурге и тихо ели грибы», в которой партнеры кратко изложили историю появления нашего продукта. Поэтому в первой статье своего Хаброблога мы бы хотели погрузиться в математические основы технологий RAIDIX.
Рубрика «raid» - 3
Начнем с математики. Векторизация вычислений в реализации технологии RAID-6
2017-04-19 в 9:15, admin, рубрики: raid, raid6, Алгоритмы, Блог компании RAIDIX, высокая производительность, конечные поля, контрольная сумма, математика, поля галуа, системное программирование, системы хранения данных, СХД, хранение данных
Восстановление хранилища данных и VMFS разделов. Поднимая EMC iomega с того свету…
2017-02-27 в 23:08, admin, рубрики: EMC, Iomega, Lenovo, raid, vmfs, VMware, виртуализация, Восстановление данных, резервное копирование, хранение данныхВсем привет!
В последнее время всё чаще сталкиваюсь с тем, что многие админы используют дешёвые СХД (SOHO) для продуктивных сред… При этом редко задумываясь о доступности данных и отказоустойчивости решения…
Увы, но не многие также задумываются о резервных копиях и бекапах…
Вот и сегодня ко мне «на лечение» попал интересный экземпляр:
Чудестный экземпляр EMC (ещё даже не Lenovo) iomega storcenter px4 (который дальше 25% не грузится)
О подробностях восстановления читайте под катом.
Читать полностью »
Миграция Xenserver 7 на linux raid
2016-08-08 в 7:30, admin, рубрики: citrix xenserver, linux, raid, виртуализация, системное администрированиеXenserver недавно обновился до седьмой версии и я, конечно же, не смог пройти мимо.
Среди бросающихся в глаза плюшек (помимо миграции на CentOS 7) — другая разбивка диска с монтируемым отдельно /var/log (наконец-то) и увеличенным до 20 гигов корнем (алиллуйя!).
Но вот делать при загрузке RAID любого уровня он так и не умеет. А значит, нужно опять мигрировать уже установленную систему.
Благо, если XenServer только-только установлен, то это не так страшно.
Всё, что вы хотели узнать о RAID-контроллерах, но лень было искать
2016-07-06 в 11:38, admin, рубрики: raid, Refurbished, Блог компании Администратор сети, ит-инфраструктура, Серверная оптимизация, Серверное администрирование
Дисковый массив с нотками ретро.
На плечах RAID-контроллеров лежит ответственная задача — управление дисковой подсистемой, то есть всей информацией, хранимой на сервере. Именно они отвечают за работу дисковых массивов, позволяя повысить производительность сервера или надёжность хранения данных. Поэтому давайте поговорим о RAID-контроллерах, установленных в серверы вендоров «большой тройки», об их возможностях и особенностях.
Читать полностью »
NetApp virtual storage appliance: Data ONTAP-v
2016-06-15 в 5:21, admin, рубрики: azure, CBvM100, Cloud ONTAP, Clustered ONTAP, Data ONTAP, Data Ontap-v, ESXi, FDvM100, FDvM200, freebsd, Fujitsu, Fujitsu PRIMERGY, IP SAN, microsoft, Microsoft Azure, NetApp, NetApp Data ONTAP, NetApp FAS, NetApp ONTAP, ONTAP, PRIMERGY, PRIMERGY BX400, raid, SAN, virtual storage appliance, VMware, VMWare ESXi, VSA, VSX960, ит-инфраструктура, Облачные вычисления, резервное копирование, хранение данных, метки: NetApp ONTAP, ONTAPПускай уже давно, но как-то незаметно, прошла новость о том, что Hyper-V а потом и Azure начал поддерживать FreeBSD. Любители старой, доброй, FreeBSD возрадовались, а многие другие люди могли недоумевать: «зачем?». Именно благодаря усилиям компании NetApp, FreeBSD теперь поддерживается в Hyper-V и Azure. Каким образом NetApp в этом заинтересована? Дело в том, что ОС ONTAP построена на базе FreeBSD. Именно для того, чтобы появились продукты созданные на базе Data ONTAP-v, такие как Cloud ONTAP и Data ONTAP Edge. Кроме того компания NetApp является одним из самых больших современных контрибюторов кода для FreeBSD.
Читать полностью »
Объектное хранилище NetApp StorageGrid
2016-05-10 в 13:18, admin, рубрики: AltaVault, amazon, Amazon CloudFront, amazon s3, archive, backup, big data, blob, CDMI, ceph, CIFS, cinder, Citrix Sharefile, cloudfront, Commvault, Ctera, DDP, docker, Dynamic Disk Pools, E-Series, Egnyte, Erasure Coding, File share, File sync, Geo-EC, glance, Inktank, Inktank Ceph, kilo, kvm, NAS, NetApp, NetApp AltaVault, NetApp E-Series, NetApp StorageGrid, nfs, NTP software, object storage, OpenStack Heat, OpenStack Kilo, raid, RESTful HTTP, s3, SCSI, SGAPI, smb, SoftNAS, stealth, StorageGrid, swift, Swift API, Symantec Enterprise Vault, Анализ и проектирование систем, ит-инфраструктура, системное администрирование, хранение данных В этой статье я отклонюсь от традиционной для меня темы систем хранения FAS и подниму тему объектного хранения данных в системах NetApp StorageGrid WebScale. Если кратко, то объектное хранение — это третий тип хранения наряду с NAS и SAN. Представьте себе, что каждый файл состоит из данных и метаинформации (владелец, права, время модификации и т.д.), так вот объектное хранение позволяет разъединить эти части и хранить их в виде «ключ/значение». Такой подход хранения информации открывает возможности децентрализованного, распределённого хранения данных огромных масштабов с прозрачной миграцией данных, репликацией и прозрачным переключением конечных потребителей между нодами объектного кластера. В широком смысле объектное хранилище может быть реализовано как на уровне устройства (жесткого диска), при помощи специализированных SCSI команд (Object-based Storage Device Commands), так и на уровне протокола доступа к системе хранения, которая состоит из нескольких дисков (которые, в свою очередь, вовсе не обязаны быть объектными). В обоих случаях используется Ethernet для подключения и IP протокол для передачи данных. Примером реализации объектного хранилища на уровне устройства являются жесткие диски линейки Seagate Kinetic Open Storage platform. Примером систем хранения данных в облаке может быть Microsoft Azure BLOB, Amazon S3. В этой статье я остановлюсь на объектных СХД, которые можно развернуть у себя на сайте и при необходимости подключить к облаку.
Читать полностью »
Какие факторы влияют на производительность систем хранения и как?
2016-04-26 в 9:40, admin, рубрики: big data, IOPS, IT-стандарты, raid, Блог компании ua-hosting.company, ит-инфраструктура, производительность, пропускная способность, размер блока, размер кластера, системы хранения, хостингСистемы хранения данных для подавляющего большинства веб-проектов (и не только) играют ключевую роль. Ведь зачастую задача сводится не только к хранению определенного типа контента, но и к обеспечению его отдачи посетителям, а также обработки, что накладывает определенные требования к производительности.
В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.
В этой статье я хотел бы рассмотреть эти факторы, чтобы сделать меру производительности, выраженную в IOPS, более понятной.
Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей. Читать полностью »
Автоматизация проверки на целостность рейд-массива на сервере Dell
2016-03-18 в 14:35, admin, рубрики: casperjs, consistency, dell, javascript, open source, perc, phantomjs, puncture, raid, системное администрированиеПривет, %хабрачитатель%!
Несколько месяцев назад у нас возникли проблемы с одной виртуальной машиной, запущенной на сервере Dell PowerEdge R720 с ESXi 5.5. Перезагрузка этой VM длилась довольно долго и вызвала сильное падение производительности на самом хосте.
Lifecycle-лог на сервере был наполнен сообщениями вида:
PDR47
A block on Disk 0 in Backplane 1 of Integrated RAID Controller 1 was
punctured by the controller.PDR64
An unrecoverable disk media error occurred on Disk 0 in Backplane 1 of
Integrated RAID Controller 1.
Гугление привело к неутешительному выводу: рейд-массив поврежден и восстановить его невозможно. А именно — повредились данные, относящиеся к одному блоку (страйпу), сразу на нескольких дисках (double fault):
К счастью, делловские RAID-контроллеры обладают фичей продолжать работу, несмотря на неконсисентное состояние массива — puncture (https://www.dell.com/support/Article/us/en/04/438291/EN#Unique-Hyphenated-Issue-Here-2), что позволяет сохранить хотя бы ту часть данных, которая не повредились. Это, конечно, не никак отменяет необходимость последующей замены дисков и пересборки рейд-массива «с нуля».
Для предотвращения подобных ситуаций Dell рекомендует запускать проверку целостности массива не реже одного раза в месяц. Увы, но мы об этом узнали слишком поздно.
Такую проверку можно запускать как через веб-интерфейс Dell OpenManage Server Administrator (http://www.dell.com/support/contents/us/en/19/article/Product-Support/Self-support-Knowledgebase/enterprise-resource-center/Enterprise-Tools/OMSA/), так и через утилиты omconfig/omreport, входящие в OMSA. И, если бы разработчики из Dell не «забыли» включить эти утилиты в OpenManage для ESXi, то проблем с автоматизацией бы не возникло, т.к. понятно, что ручная проверка целостности массива на каждом сервере, совершенно не IT-way. Не говоря уже о том, что интерфейс OMSA очень медленный и работать с ним удовольствие еще то.
Ребята из Dell «поработали на славу» и простым способом автоматизировать проверку (например, через открытие в cURL заранее подготовленной ссылки) невозможно, т.к. веб-интерфейс генерируется динамически и постоянные ссылки в нем отсутствуют.
Что же делать? Читать полностью »
Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 3, заключительная)
2015-08-26 в 16:45, admin, рубрики: diy или сделай сам, Dr. Tariff, performance, postgresql, raid, sql, ssd, Ubuntu, базы данных, Блог компании Dr. Tariff, Железо, операционные системы, Процессоры 
Пора провести финальные тесты и подвести итоги цикла статей. Сегодня мы рассмотрим влияние размера shared_buffers на производительность БД. Первые части можно почитать здесь и здесь.
В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.
Тестируем PostgreSQL на SSD RAID-0 массиве с таблицей в 10 миллиардов записей. (Часть 2)
2015-08-25 в 14:13, admin, рубрики: diy или сделай сам, Dr. Tariff, performance, postgresql, raid, sql, ssd, Ubuntu, базы данных, Блог компании Dr. Tariff, Железо, операционные системы, Процессоры 
Итак, продолжим исследовать характеристики работы PostgreSQL на SSD и HDD дисках с целью повышения производительности системы. Первую часть можно почитать здесь.
В ходе развития сервиса оптимизации затрат на сотовую связь Dr. Tariff (iOS, Android) для совместного пилота с одним из партнеров нам потребовалась большая и производительная реляционная база данных.
В этот раз мы протестировали PostgreSQL на RAID-0 массиве из двух SSD дисков. RAID массив собирался с помощью mdadm. Размер страйпа (блока информации, который распределяется на все диски массива) – 512k.
Читать полностью »