источник:
Мобильные телекоммуникации №5, 2008
Информационная система оператора связи должна быть хорошо сбалансирована и не иметь отдельных перегруженных компонентов. Если говорить о такой ее составляющей, как биллинговая система, то обязательными требованиями к ней являются гибкость, производительность, возможность масштабирования. Наряду с этим возрастает роль подсистем хранения данных: с ростом абонентских баз, появлением новых видов услуг возрастает и объем данных, которые нужно обрабатывать и сохранять. Данные перестают умещаться в кэш-памяти серверов приложений и СУБД, и необходимость обращения к подсистеме хранения данных начинает все больше увеличивать время отклика биллинговой системы.
Поэтому очень важно правильно спланировать и настроить систему хранения данных (СХД) с точки зрения как производительности, так и доступности информации (что, в свою очередь, предполагает отказоустойчивость и возможность резервирования данных), а также с учетом совокупной стоимости владения. Как показывает опыт, ошибки при планировании СХД не всегда могут компенсироваться возможностями масштабирования программных комплексов биллинговых систем. Рассмотрим некоторые вопросы, на которые стоит обратить внимание при планировании СХД для биллинговой системы.
Планирование Производительности системы хранения данных
Для обеспечения надежного хранения информации большинство поставщиков решений СХД сегодня предлагают RAID-массивы (Redundant Arrays of Inexpensive Disks). Наиболее распространенные и отказоустойчивые уровни RAID — это RAID 1, RAID 5 и составные массивы RAID 0+1 (01) /1+0 (10). В массивах уровня 1 надежность достигается за счет зеркалирования — идентичные копии данных записываются на два или более дисков. В массивах уровня 5 используется принцип чередования (распределение порций данных в пределах массива) с распределенным контролем. Этот уровень RAID является самым экономичным с точки зрения использования дополнительного (дублирующего) дискового пространства. Однако считается, что при частых случайных изменениях данных, характерных для задач оперативной обработки транзакций (OLTP), производительность RAID 5 ниже, чем у RAID 1 или 10, но высока при считывании данных, что характерно для работы систем поддержки принятия решений (DSS). В настоящее время поставщики решений совершенствуют механизмы работы систем, подобных RAID 5, за счет специальных алгоритмов кэширования, и в ряде случаев производительность массивов RAID 5 может быть близка к таковой у RAID 1(10).
В ходе тестирования производительности СУБД при больших объемах записи на разных конфигурациях RAID-массивов (примеры см. [2, 3]) уровень RAID 5 показывает примерно на 7-12% худшую производительность по сравнению с конфигурациями RAID 1 (10). В то же время при изменении большого объема смежных данных конфигурация RAID 5 показывает даже лучшие результаты, что можно объяснить механизмами оптимизации записи из кэша массива, когда последовательные операции записи преобразуются в операцию записи full stripe с формированием контрольной суммы однократно на записываемую порцию (stripe). В упомянутых тестах использовались конфигурации с одинаковым количеством дисков в вариантах RAID 10 и RAID 5, поэтому, как было отмечено выше, RAID 5 имеет преимущество в доступном объеме пространства хранения.
С точки зрения биллинговой системы и СУБД, на которой она базируется, скорость работы СХД определяется не только пропускной способностью системы (Мбайт/с), но и количеством операций ввода-вывода в единицу времени (IOPS). При эксплуатации биллинговой системы часто именно количество операций ввода-вывода становится ограничивающим фактором. Увеличению показателя IOPS способствует большее количество дисков в массиве и те методики повышения производительности, которые предоставляет контроллер RAID, к примеру кэширование.
Ориентировочно рассчитать количество дисков в массиве, способное обеспечить необходимую пропускную способность (IOPS), можно по формуле, приведенной в статье [1]:
g=r/c= к+1/kcxt.
где с — максимальное количество операций ввода-вывода для каждого жесткого диска;
r — общее количество физических операций ввода-вывода в секунду, которые требуются от RAID-массива;
k — размер сегмента чередования, деленный на размер блока ввода-вывода;
t — общее количество операций ввода-вывода, которое будут генерировать одновременно работающие транзакции.
Указанная формула может использоваться для расчета дисковых массивов RAID 0 и RAID 10.
Если использовать эту технику для расчета массива RAID 5, то следует увеличить оценку необходимого количества запросов ввода-вывода на одну транзакцию для отражения того факта, что этот массив имеет большие издержки при выполнении каждой операции записи. Так, в тесте, описанном в статье [2], при нагрузке СУБД Oracle, создаваемой большим количеством случайных операций UPDATE, для массива RAID 5 выполнялось в среднем в 1,6 раза больше физических операций ввода-вывода по сравнению с конфигурацией RAID 10.
На практике довольно трудно оценить требуемую пропускную способность системы как в Мбайт/с, так и в IOPS, особенно с учетом потребностей в развитии системы. Если система уже эксплуатируется, можно прогнозировать ее пропускную способность, исходя из таковой в существующей системе, и аппроксимировать ее для ожидаемого роста нагрузки на СХД. Для вновь развертываемой системы можно воспользоваться нагрузочными тестами поставщика решений. В любом случае динамика развития бизнеса и возникновение новых потребностей могут нуждаться в не предусмотренных на этапе планирования мощностях, поэтому важным свойством системы является ее способность к масштабированию «на ходу», без прерывания рабочего процесса. Многие инновации, вводимые производителями СХД, направлены именно на возможность расширения СХД и наиболее полное использование имеющихся мощностей.
Итак, при планировании и конфигурировании СХД следует иметь в виду следующие аспекты.
1. Важным параметром производительности СХД является количество операций ввода-вывода в единицу времени (IOPS), которое должна обеспечить система.
2. И RAID 5, и RAID 10-конфигурации жизнеспособны для большого диапазона рабочих нагрузок.
При этом конфигурации RAID 10 будут иметь преимущество при нагрузке с большим количеством случайных записей, а RAID 5 — при операциях последовательных чтений и записей.
3. Как приведенные тесты поставщиков СХД, так и опыт заказчиков, эксплуатирующих
решения «Петер-Сервис», показывают, что в большинстве случаев конфигурация массива
с распределением данных СУБД по всем дискам (одна дисковая группа) является достаточно
эффективным и гибким решением, которое позволяет получить хорошо сбалансированную
нагрузку на СХД без необходимости детального анализа и ручного распределения файлов СУБД по устройствам.
Новые технологии в системах хранения данных
С точки зрения эксплуатации биллинговых систем и СУБД, на которых они базируются, могут
быть интересны технологические инновации, предлагаемые поставщиками решений СХД.
Общая тенденция таких инноваций — стремление к максимально полному использованию и гибкому управлению имеющимися ресурсами хранения данных. Это позволяет, наряду с возможностями динамического расширения емкости дисковых массивов и виртуализации хранилища, строить масштабируемые и легко управляемые системы.
Технология экономичного выделения Пространства в хранилище данных
(Thin Provisioning)
Сегодня это одна из наиболее интересных технологий в области систем хранения данных.
Она дает возможность использовать объемы хранилища, исходя из имеющегося объема данных, путем уменьшения выделенного (allocated), но неиспользуемого пространства.
Например, имеется 300 Гбайт данных и логический том 1 Tбайт, созданный исходя из расчетных потребностей при росте системы, — получаем 700 Гбайт пустых блоков, которые выделены, но не используются. Технология Thin Provisioning решает эту проблему: можно создать том 1 Tбайт, но только 300 Гбайт из него будут выделены фактически, а 700 Гбайт смогут в текущий момент использоваться под другие нужды и находиться в общем свободном пуле.
Технология Thin Provisioning предоставляет следующие преимущества:
• уменьшение «потерянного» пространства и соответственно уменьшение потребности
в дополнительном пространстве в ходе расширения системы;
• обслуживание системой хранения данных большего количества приложений/серверов;
• уменьшение затрат времени и ресурсов на выполнение задач выделения пространства хранения;
• снижение энергопотребления и затрат на охлаждение вследствие более экономичного использования имеющихся ресурсов хранения.
Применение Thin Provisioning вместе с возможностями СУБД по управлению пространством (например, Oracle ASM, Auto-Extend) позволяет существенно снизить затраты на управление системой хранения и улучшить использование пространства [5].
Сегодня технологию Thin Provisioning в свои системы внедряют такие «гранды» рынка, как Hewlett-Packard (HP StorageWorks — HP Thin Provisioning), NetApp (в линейке «унифицированных систем» FAS), EMC (Celerra NS) и HDS (Tagmastore USP).
Динамическое управление томами (Dynamic Volume Management, DVM)
DVM-технология выполняет функции, схожие с Thin Provisioning. Dynamic Volume Management — это способность изменить объем логического тома, в то время как он продолжает работу (on-line), без перезапуска системы. Сервис DVM предоставляет операционная система хоста, и система хранения должна поддерживать эти возможности. Примером внедрения такой технологии может служить Dynamic Volume Expansion компании IBM.
SNAPSHOTS
При тех объемах данных, которые генерируют информационные системы современных операторов связи, создание резервных копий и восстановление системы традиционными способами копирования в операционных системах становится проблематичным. Поэтому важное значение приобретают механизмы клонирования данных внутри хранилища.
Одним из вариантов таких технологий являются «мгновенные снимки» — Snapshots.
Объем дискового пространства для хранения снимка определяется объемом модернизированных данных, которые появились с момента создания предыдущего снимка. К примеру, если в 8 часов утра мы сняли Snapshot с LUN объемом 1 Tбайт, а к 18 часам вечера в исходных данных поменялось 20% информации, снимок станет занимать 200 Гбайт, что, конечно же, значительно меньше, чем при создании клона.
Snapshots позволяют снизить расходы за счет уменьшения емкости, необходимой для хранения копий:
• рабочее пространство используется только для хранения обновляемых данных;
• не требуется выделять емкость на копию тома, равную полной емкости тома-источника;
• экономное выделение дискового пространства для целевых копий позволяет уменьшить общую необходимую емкость.
Развитие технологий кэширования и Prefetching
Технологии Prefetching позволяют ускорить выполнение некоторых операций, выполняемых СУБД. Например, при сканировании таблиц DB2 функция AMP (Adaptive Multi-stream Prefetching), реализованная в СХД IBM DS8000, показывает пропускную способность, аналогичную получаемой при считывании непосредственно из кэш-памяти [7]. Большое количество операций сканирования таблиц присуще DSS-системам, но может быть характерно и при начальной загрузке серверов приложений, работающих с актуальным срезом данных биллинговой системы, загрузке оперативных кэшей и др. При эксплуатации высокопроизводительных систем поддержки биллинга, например систем самообслуживания абонентов, систем тарификации и обслуживания в реальном времени, используется кэширование данных запросов. Примером таких систем могут служить решения PETER-SERVICE BISrt, PETER-SERVICE SCC и PETER-SERVICE HRS. Такие системы способны также получить выигрыш от улучшения скорости последовательного сканирования при начальной загрузке.
Массив с Простаивающими дисками (MASSIVE ARRAY OF IDLE DISKS, MAID)
MAID представляет собой систему хранения, в которую включены только те диски массива, которые используются в текущий момент. Это уменьшает энергопотребление и увеличивает срок эксплуатации дисков. Ограничениями MAID являются меньшая пропускная способность, чем у обычных дисковых массивов, и большее время реакции. Это не позволяет использовать их в качестве первичных хранилищ для СУБД, но они могут применяться для хранения архивных журналов, резервных копий и т. п.
Литература
1. Carry V. Millsap. Конфигурирование сервера Oracle для сверхбольших баз данных. 1996.
2. IBM TotalStorage Enterprise Storage Server Model 800 — RAID 5 and RAID 10 Configurations Running Oracle Database Performance Comparisons. IBM Systems Group. Open Storage Systems Laboratory. San Jose. CA.
3. Performance evaluation of Oracle 10g on HP StorageWorks Enterprise Virtual Array (EVA). Hewlett-Packard Development Company.
4. Tony Asaro. Power, Cooling, Space Efficient Storage. Enterorise Startegy Group.
5. Lowering database storage complexity and management cost with HP Thin Provisioning XP and Oracle Database10g and 11g. HP Storage Works Division. December 2007.
6. HP StorageWorks XP12000 Disk Array best practices for performance guidelines. White paper.
7. Римма Владимирова. DS8000 — основа высокопроизводительной инфраструктуры хранения данных для бизнес-критических приложений // Материалы Форума IBM. СПб. 25 марта 2008 г.
8. Обзор систем хранения данных Hitachi Universal Storage Platform V/VM. Hitachi Data Systems. 2007.