Одним из наиболее динамичных секторов рынка в нашей стране являются розничные сети и сети оптово-розничных складов. Укрупнение компаний и консолидация бизнеса компаний приводит к ужесточению требований к ИТ-инфраструктуре. Оптимизация ИС предполагает внедрение и использование новых аппаратных и программных средств, позволяющих повысить эффективность бизнеса.
Оптово-розничные сети и сети складов, особенно продуктовых и аптечных, работают с большим количеством товарных позиций. Эта специфика обуславливает обширный номенклатор, предусматривающий учет товаров с рядом уникальных параметров (например, цветом). Для большинства сетей актуальным является жесткий партионный учет товарных запасов, связанный со сроком годности конкретной партии товара или наличием сертификата соответствия, в результате чего в подобных системах реализуется относительно сложная складская логистика. На уровне розничных продаж для сетей магазинов и супермаркетов характерен огромный поток данных от касс в торговом зале, объем которых, как правило, отрабатывается в режиме online относительно остатков в торговом зале и в режиме off-line относительно партионного учета товаров, остатков на складах, транспортной и складской логистики.
Особого подхода к автоматизации учета требуют товары без штриховых кодов. Это усложняет, а иногда делает невозможным или неоправданно дорогим автоматизированный учет в режиме online. Для некоторых товаров необходимо учитывать усушки, утруски, что требует реализации нетривиальных алгоритмов в учетной системе. Бой товаров в пути, пересортица, ошибки в документах поставщиков и другие факторы заставляют учетные системы работать “задним числом”, в конце месяца восстанавливая фактическую последовательность в партионном учете по большинству подразделений сети. Задачи обработки и получения консолидированных данных в информационных системах, работающих в режиме online, требуют значительных вычислительных ресурсов и скоростной системы хранения данных. Актуальной является проблема организации работы мобильных пользователей с минимальным уровнем затрат на техническое обеспечение и требуемой функциональностью. Таким образом, крупные розничные и оптовые торговые компании формируют комплекс требований к центру обработки данных (ЦОД) и сети хранения данных (СХД).
Требования к аппаратным ресурсам
Ресурсы СХД должны обеспечивать регламентированный ежедневный обмен данными между периферийными и центральной БД или работу этих систем в режиме on-line в рамках единой автоматизированной системы управления предприятием (АСУП). При этом необходимо обеспечить, помимо производительности, достаточный уровень отказоустойчивости и доступности информации.
Часто, кроме оперативной БД, которая обеспечивает поточную деятельность, компании организуют отдельную аналитическую БД для аналитиков из отдела логистики, финансов и аудита. Для аналитических систем, как правило, должна быть обеспечена возможность проведения перерасчета с восстановлением партионного учета для центральной БД предприятия на глубину около 1 месяца в течение 3-7 дней, а на глубину квартала — не более 10–12 дней. Нередко “отягчающим” обстоятельством служит наличие (по крайней мере на нижнем уровне) устаревших или плохо интегрируемых систем сбора данных. В этом случае для конвертирования и синхронизации данных требуются дополнительные ресурсы систем хранения и вычислительные мощности.
На практике модернизация аппаратно-программного обеспечения ЦОД часто бывает приурочена к внедрению новой ERP-системы. Это налагает дополнительные требования — система должна быть оптимизирована под разные наборы ПО и некоторое время выдерживать параллельную работу как новой, так и старой системы.
Требования к дисковым массивам
Практика построения ЦОД для нужд ERP-систем показывает, что определяющими являются требования, предъявляемые к сети хранения данных и ее строительным блокам — отдельным хранилищам. Как правило, в СХД работают хранилища с типом подключения, интерфейсами, уровнем производительности и отказоустойчивости. Многие компании начинают с использования подключаемых напрямую к серверам хранилищ (DAS), которые впоследствии могут стать частью комплексной СХД.
Исходя из требований бизнеса, аппаратные ресурсы хранилища данных должны предусматривать работу по меньшей мере двух одинаковых по объему БД — оперативной и аналитической, которые генерируют разную нагрузку на дисковый массив. У оперативной БД основными критериями являются скорость потока записи и способность обрабатывать большое количество одновременных обращений к данным. Аналитические базы данных обслуживают меньшее количество пользователей, однако нагрузка, генерируемая каждым запросом, выше, поскольку отчетность формируется за длительный период и по широкой выборке данных. Такие запросы создают значительный поток на чтение.
Совмещение оперативной и аналитической базы данных на одном дисковом массиве приводит к снижению производительности оперативной БД, что вынуждает применять специфические методы оптимизации. К ним относится разделение массива на логические разделы (LUN) с одновременной оптимизацией работы кэш-буфера и возможность использования в нескольких RAID-массивах. Для полного исключения взаимного влияния оперативную и аналитическую базы данных располагают на разных аппаратных дисковых массивах.
Отказоустойчивость системы хранения обеспечивается использованием избыточных внутренних компонентов и внешних интерфейсов. Максимальный уровень доступности гарантирует подключение дискового массива к двум независимым серверам БД по двум каналам FC. Такая схема фактически позволяет устранить единую точку отказа. Конечно, для реализации такого подключения необходимо, чтобы дисковый массив допускал установку резервного RAID- и FC-контроллеров, а также создание независимых логических разделов. Примером подобной конфигурации может служить дисковый массив, поддерживающий SAS- и SATA II-диски, где более производительные SAS-диски обычно выделяют для оперативной базы данных, а для аналитической — более емкие, но дешевые SATA. Для удобного и быстрого создания резервных копий востребована аппаратная поддержка дисковым массивом функции SnapShot.
Конфигурации дисковых массивов
Выбирая дисковый массив для приложений БД, следует обратить внимание на отличия в базовой и полной конфигурации. В базовую поставку производители часто включают только один контроллер FC и RAID, предлагая второй в качестве дополнительной опции. Этот вариант можно считать приемлемым для систем, которые не обслуживают критичные к готовности приложения. Также на рынке представлены массивы с урезанным объемом кэш-памяти. Эта система на 2–3% дешевле, что может обеспечить победу в тендерах. Такая экономия сказывается на производительности массива — хранилища с уменьшенным объемом кэша лучше использовать в качестве резервных.
Полные конфигурации, оснащенные двумя управляющими блоками, сохраняют работоспособность даже в случае выхода из строя одного из управляющих блоков. Возникновение аварийной ситуации не приводит к полному отказу дискового массива и остановке системы. Оба контроллера имеют независимый доступ ко всем жестким дискам и снабжены внешними FC-интерфейсами. Резервирование питания в дисковых массивах достигается установкой двух или трех блоков питания с горячей заменой. Совокупность этих решений практически устраняет возможность отказа дискового массива.
Массивы DAS, снабженные двумя управляющими блоками, позволяют создать основу для хранения данных и впоследствии могут быть использованы в качестве строительного блока сети хранения данных SAN. Этот подход позволяет продлить жизненный цикл системы и снизить стоимость владения ею.
Требования к серверам
Для обеспечения максимальной производительности и отказоустойчивости в ЦОД принято использовать кластеры серверов БД, состоящие как минимум из двух узлов. В минимальной конфигурации такие системы обеспечивают подключение каждого узла к дисковому массиву (DAS) по двум каналам FC. При этом каждый узел имеет независимое подключение к обоим управляющим блокам дискового массива. Наличие четырех FC-каналов у дискового массива позволяет подключать к нему напрямую четыре сервера БД, однако в проектах такого масштаба рационально переходить от прямого подключения к построению SAN.
Естественным путем повышения отказоустойчивости, производительности и масштабируемости серверов приложений является объединение их в кластер. Сегодня все ведущие платформы для развертывания полноценной системы управления предприятием, в том числе SAP, MS Dynamics и др., поддерживают режим кластеризации. Выбор аппаратного обеспечения сервера приложений необходимо производить, опираясь в первую очередь на требования конкретных приложений и БД. Оптимальный путь — создание собственного тестового стенда и проведение замеров на реальных данных организации. Как правило, производители готовы предоставить оборудование и технологические площадки для проведения таких тестов.
Заключение
Наиболее эффективно инвестировать деньги в строительство ИС могут те компании, которые перед покупкой техники самостоятельно оценят производительность разных строительных блоков на реальных приложениях. Оснащенные интерфейсом FC дисковые массивы с прямым подключением (DAS) по-прежнему являются базовым элементом решений, обслуживающих ERP-системы. К достоинствам DAS можно отнести высочайшую отказоустойчивость, доступность для критических приложений, гибкость при конфигурировании. Они предоставляют возможность настроить параметры так, чтобы добиться максимальной производительности при решении конкретной задачи. Такие массивы на начальном этапе могут работать по схеме прямого подключения, а впоследствии стать основой расширения в FC-сети (SAN).
