RS-Solutions

Прежде чем окончательно остановить свой выбор на конкретном решении и его составляющих, важно проработать и получить правильные, построенные на реальных данных ответы на следующие принципиальные вопросы:

• Оптимальна ли выбранная архитектура в принципе?
• Оценены ли риски выбранного решения?
• Обеспечена ли совместимость отдельных компонентов между собой и с приложением?
• Соответствует ли заявленная производительность конкретным требованиям?
• Какова реальная масштабируемость решения, насколько она адекватна бизнес-требованиям к приложению и экономически целесообразна?
• Проводились ли реальные нагрузочные тесты?
• Перспективна ли выбранная платформа?
• Всё ли системное ПО надлежащим образом учтено в бюджете проекта?
• Рассматривались ли варианты хостинга, аутсорсинга, аренды оборудования и специальных схем финансирования?
• Каков общий начальный бюджет проекта и насколько он реален?
• Какова реальная стоимость владения за 3-5 лет?
• Корректно ли произведён подсчёт стоимости лицензий на системное ПО?
• Каким образом будет организована единая техническая поддержка?
• Кто будет отвечать за администрирование и развитие приложения и ИТ-инфраструктуры?
• Каковы требования к доступности и катастрофоустойчивости, как будет организовано восстановление при сбоях, насколько выбранный вариант работоспособен?
• Какова политика резервного копирования?
• Каково энергопотребление и тепловыделение оборудования, где оно будет размещаться?

Структурная схема программно-аппаратного комплекса дистанционного банковского обслуживания клиентов

• разработка методологии и плана тестирования;
• создание стенда на выбранной программно-аппаратной платформе;
• подготовка тестовых данных;
• генерация максимально адекватных нагрузок;
• возможная оптимизация решения, корректировка спецификаций;
• согласование решения с вендорами оборудования и ПО.

Результатом такой работы станет оптимизация решения, корректное обоснование бюджета, общее снижение рисков проекта, а также обретение заказчиком уверенности в правильности выбора и реальных возможностях платформы.

Во всех случаях подобную информацию рекомендуется получать в соответствии с типовым предпроектным опросником, но зачастую требуются рабочие встречи с представителями ИТ-подразделения заказчика, а в отдельных случаях — проведение 1-3-дневного аудита непосредственно на площадке заказчика.

Немаловажными параметрами, влияющими на выбор решения, будут:

• Средняя допустимая продолжительность незапланированного простоя в день.
• Возможность плановых остановов системы в заранее оговоренное время для выполнения регламентных работ, установки обновлений и проч.
• Целевая точка восстановления (RPO; интервал времени, за который допустимо потерять транзакции).
• Целевое время восстановления (RTO; допустимый интервал времени восстановления после аварии).
• Режим планируемой эксплуатации внедряемой системы.
• Количество пользователей системы.
• Количество одновременно работающих пользователей системы.
• Перечень планируемых к использованию функциональных модулей системы.

Например, в авиации адекватно оцениваются риски и важность выполнения задачи. Специальные решения по повышению надёжности применяются уже более 100 лет. В большинстве случаев они позволяют выполнить задачу даже в очень сложных условиях и без потерь вернуться на базу...

Доступность приложения складывается из доступности его компонентов и связей между ними. Каждый компонент, в свою очередь, представляет собой сложную совокупность вложенных элементов и внутренних взаимосвязей. На вершине иерархии находятся информационные сервисы, предоставляемые приложением, и связи между информационной системой и пользователями.

Меры по поддержанию высокой готовности можно разделить на локальные и распределённые. Локальные меры направлены на достижение высокой готовности отдельных аппаратных и программных компонентов.

Примером подобной меры может служить применение кластерных конфигураций в качестве платформы серверов СУБД или горячее резервирование активного сетевого оборудования с автоматическим переключением на резерв.

Распределённая конфигурация подразумевает использование более чем 1 площадки, где размещаются инфраструктуры. Причём полный выход из строя одной из площадок (допустим, в результате стихийного бедствия, теракта и проч.) не должен драматически сказаться на функционировании приложения в целом.

Распределённая конфигурация приложения не должна содержать одиночных точек отказа. Выход из строя основной или резервной площадок, одной из линий связи между основной и резервной площадками, одной из линий связи между головным офисом и филиалами не должен приводить к недоступности информационных сервисов приложения. Это значит, что помимо дублирования необходимо предусмотреть средства автоматического или быстрого ручного реконфигурирования серверных и коммуникационных компонентов информационной системы.

Критически значимым для обеспечения функционирования приложения является защита от сбоев сервера баз данных (СУБД). Применительно к защите СУБД Oracle Enterprise Edition наиболее распространёнными считаются две технологии:

1. Кластерное решение Oracle Real Application Clusters (RAC) поддерживает размещение одной базы данных на кластере серверов, обеспечивая непревзойдённую отказоустойчивость, производительность и масштабируемость без необходимости вносить изменения в приложение. Главное достоинство этого решения — реальное использование всей вычислительной мощности всех узлов кластера (иными словами, резервных, не применяемых в нормальной ситуации узлов, просто нет). Также среди его существенных преимуществ можно выделить:

• Готовность в режиме «24 х 7» — обеспечивает бесперебойную работу приложений баз данных.
• Масштабируемость по мере надобности — для увеличения ёмкости достаточно просто добавить серверы к кластеру.
• Более низкие затраты на обработку данных — допустимо задействовать недорогие персональные компьютеры, что позволит снизить издержки из-за простоя.
• Лучший в мире показатель производительности — работает быстрее самого быстрого мейнфрейма.
• Распределённые вычисления — Oracle RAC по сути служит основой распределённых вычислений.

Подробная техническая информация размещена по адресу:

http://www.oracle.com/technology/products/database/clustering/index.html

В качестве определённого недостатка следует отметить необходимость лицензирования всех узлов кластера, что может привести к достаточно высокой общей стоимости решения.

2. Другая технология, также помогающая повысить доступность баз данных, — Oracle Standby. Это решение основано на передаче с основного сервера на резервный файлов с логическими журналами транзакций. Резервный сервер, постоянно работающий в режиме восстановления (и, следовательно, представляющий собой теплый резерв), «накатывает» изменения, получаемые в асинхронном режиме. Предлагаемая в рамках Oracle Database Server реализация режима Oracle Standby характеризуется — благодаря интегрированности с остальными компонентами СУБД — высокой эффективностью и надёжностью, позволяет поддерживать синхронную копию БД на удалённом узле, в том числе в рамках катастрофоустойчивых конфигураций.

Важно заметить, что во многих случаях при применении Oracle Standby лицензирования потребует только один из узлов кластера, что может снизить общую стоимость решения по сравнению с Oracle RAC. Подчеркнём, что именно Oracle Standby наиболее часто отдаётся предпочтение при внедрениях приложений R-Style Softlab.

Подробная техническая информация размещена по адресу:

http://www.oracle.com/technology/deploy/availability/index.html

Как лицензии на Oracle Database Server EE, так и лицензии на Oracle Real Application Clusters могут быть предложены компанией R-Style Softlab на специальных, крайне выгодных условиях — ASFU (Application Specific Full Use), т.е. для использования только с приложениями R-Style Softlab. Это позволит в ряде случаев существенно снизить затраты на развёртывание необходимой инфраструктуры при внедрении приложений.