Как и при проектировании традиционного центра обработки данных, при развертывании Cognos в облачной среде может возникнуть необходимость использования нескольких серверов, а, следовательно, нескольких образов. Для достижения заданного уровня производительности, масштабируемости и высокой готовности обычно приходится использовать многоузловые топологии. Наша статья познакомит вас с проверенными методиками управления такими многоузловыми конфигурациями.
Эта статья – первая из серии статей, в которых приводятся советы по установке и настройке Cognos в среде облачных вычислений. В этой серии статей описывается работа с Cognos версии 8.
Прежде чем перейти к рассмотрению вопросов работы с несколькими образами ПО и достижения заданного уровня производительности и масштабируемости, давайте выясним, что представляют собой облачная среда и рабочие нагрузки, а также узнаем о том, как Cognos 8 может использовать всю мощь облачных вычислений.
Cognos 8 BI: пристегните ремни
Для тех, кто еще не знаком с Cognos 8 BI, скажем несколько слов об этом продукте.
IBM® Cognos® 8 Business Intelligence (BI) входит в состав портфеля продуктов IBM Information Management, который помимо Cognos BI содержит такие программные продукты, как DB2®, Cloudscape, InfoSphere™, Optim™, FileNet®, Informix® и OmniFind®, предназначенные для решения самых разнообразных задач, в число которых входят анализ, управление информацией и базами данных, управление корпоративным содержимым и соответствием, обмен сообщениями, совместная работы, а также разработка порталов и mashup-приложений. Решение Cognos вместе с программным обеспечением для статистического анализа SPSS образуют подразделение IBM Business Analytics.
IBM Cognos 8 BI состоит из четырех основных проблемно-ориентированных компонентов.
- IBM
Cognos 8 BI Reporting – единое Web-решение, предназначенное для формирования отчетов и работы с ними на протяжении всего жизненного цикла и обладающий следующими возможностями:
- Получение отчетов в режиме самообслуживания, позволяющие пользователям получать требуемую информацию без привлечения ИТ-специалистов.
- Подход "написать один раз, использовать везде", позволяющий ИТ-специалистам создавать отчеты, доступные пользователям большого числа различных устройств. Поддерживаются более 25 языков, несколько различных форматов, а также доступ из других приложений и процессов.
- IBM Cognos 8 BI Analysis – компонент, позволяющий работать с информацией в интерактивном режиме независимо от того, где она хранится (аналитическая обработка в реальном времени и многомерные реляционные источники). Cognos 8 BI Analysis позволяет быстро выполнять сложный анализ, переходить от уровня обобщений к уровню детальных транзакций для получения необходимой информации, а также содержит встроенные настраиваемые временные ряды, с помощью которых можно выявлять и детально исследовать тенденции изменений, происходивших в компании за предшествующие периоды времени.
- IBM Cognos 8 BI Dashboards – компонент, предназначенный для мониторинга, оценки и управления эффективностью предприятия и позволяющий получать наглядные сводные представления данных из различных источников. Cognos 8 BI Dashboards является ключевым инструментом анализа, позволяющим предотвращать возникновение проблем на самой начальной стадии. Информационные панели позволяют создавать любые графические представления данных и просматривать результаты в различных форматах.
- IBM
Cognos 8 BI Scorecarding – компонент, помогающий анализировать отчеты, получаемые с помощью информационных панелей, переводить их в численные показатели и разрабатывать на их основе долгосрочную стратегию развития бизнеса. Cognos 8 BI Scorecarding помогает донести эту стратегию до сотрудников других подразделений путем разработки системы показателей, по которым они могут оценивать результаты своих действий, и выступает в роли стратегического центра управления бизнес-процессами всей компании.
- Для каждого показателя может быть назначен владелец.
- Для каждой системы показателей может быть назначен приоритет в соответствии с общей стратегической картой.
- Каждая система показателей может содержать встроенные аналитические инструменты, позволяющие проводить анализ быстро меняющейся ситуации.
- Каждую систему показателей можно просматривать в контексте карты общей стратегии, чтобы получить представление о том, насколько она согласуется с общим планом развития компании.
Существуют также другие компоненты, расширяющие функциональность Cognos 8 BI.
Cognos 8 BI: поднимаемся в облака
Мы считаем очевидным, что мощные программные продукты для бизнес-анализа и среда облачных вычислений прекрасно дополняют друг друга. Обе концепции позволяют избавиться от ограничений, присущих традиционным информационным системам.
- Облачные вычисления обеспечивают возможность совместного использования виртуальных и физических информационных ресурсов и избавляют от необходимости располагать их на одной машине. Распределение нагрузки между несколькими информационными системами внутри (а иногда и за пределами) облака позволяет решать вопросы нехватки вычислительных ресурсов в пиковые периоды. Заранее создавая предварительно настроенные, включающиеся по запросу тестовые системы и рабочие приложения, можно сократить удельные затраты на доступ к системе.
- Инструменты бизнес-анализа берут на себя всю трудоемкую работу по выявлению тенденций и отклонений, автоматизируют ее, а также предоставляют информацию в наглядном виде, позволяющем понять и проанализировать тенденции развития компании. Эти инструменты позволяют находить возможные решения на основе проведенного анализа, превращая информацию в знания и позволяя ответить на самый главный вопрос: "Куда двигаться дальше?"
В этой серии статей мы рассмотрим ряд проверенных методик, основанных на нашем личном опыте. Мы обсудим следующие вопросы.
- Управление многоузловыми конфигурациями Cognos в облачной среде, ориентированное на обеспечение производительности, масштабируемости и высокой готовности Cognos-приложений. Мы обсудим использование файла hosts для управления несколькими образами, масштабирование кластера до различных размеров, создание моментальных снимков состояния с помощью частных образов, а также способы хранения необходимых файлов.
- Оценка требований к конфигурации системы для обеспечения производительности и масштабируемости. Мы поговорим о том, как зависит производительность Cognos-решений от сложности приложений, а также от различных групп пользователей и их географического распределения. Также будут рассмотрены дальнейшие действия после развертывания необходимой конфигурации.
- Выбор конфигурации для обеспечения высокой готовности. Вы получите несколько рекомендаций по настройке и сопровождению Cognos-решений в облачной среде, позволяющих обеспечить высокую готовность и восстановление системы после сбоев. Мы рассмотрим использование шлюзов и серверов приложений Cognos, использование менеджера управления контентом Cognos Content Manager в активном и резервном режимах, а также систему обеспечения высокой готовности и восстановления после сбоев HADR (IBM DB2 High Availability and Disaster Recovery).
- Общие вопросы конфигурирования, защиты и работы с данными. Мы поговорим о различных рабочих нагрузках и требованиях, а также о том, где в каждом случае необходимо размещать файлы, базы данных и источники аутентификации.
Если у читателей возникнет интерес, в будущих статьях мы можем рассказать о различных приемах защиты и вариантах установки Cognos 8 BI в облаке IBM Cloud.
Начнем нашу серию с рассмотрения краткого (и далеко не полного) списка вопросов, которые необходимо учитывать при проектировании и тестировании конфигурации Cognos.
С чего начать работу с облаком
При проектировании и модернизации вашей конфигурации придерживайтесь следующих правил.
- Начните с простого. Обеспечьте соблющение необходимых требований, но не усложняйте конфигурацию без лишней необходимости.
- В конфигурации вашего облака всегда должно присутствовать минимально необходимое количество экземпляров. Добавить дополнительные экземпляры очень легко, поэтому можно уменьшить начальные требования.
- Второй пункт также относится к количеству уникальных образов в облаке. Например, всегда проще управлять одним образом самонастраиваемой базы данных DB2, чем создавать пять различных образов СУБД.
- Процесс проектирования и тестирования вашей конфигурации должен быть итерационным. Например, рабочий цикл может иметь следующий вид.
- Проектирование/модернизация конфигурации.
- Создание/подготовка необходимых экземпляров.
- Установка/настройка экземпляров.
- Сохранение снимков состояния образов.
- Проверка функциональности системы и оценка ее производительности.
- Повторение всех шагов.
Теперь давайте перейдем к главной части статьи – проверенным методикам управления многоузловыми конфигурациями Cognos в облачной среде.
Использование файла hosts для управления несколькими образами
При работе в многоузловой облачной среде приходится учитывать, что этим образам назначаются различные и меняющиеся IP-адреса.
Имена узлов и соответствующие им IP-адреса, как правило, хранятся в базах DNS-серверов, с помощью которых выполняется прямое и обратное сопоставления. Например, IP-адрес резервного менеджера управления контентом 10.3.0.1 может быть сопоставлен имени узла cm_standby.
В дополнение к использованию файлов hosts на каждом компьютере для сопоставления имен в сложных решениях может оказаться полезным настроить внутренний DNS-сервер. Файл hosts используется операционной системой для сопоставления имен узлов их IP-адресам, и во многих случаях он же используется для управления кластером.
- В операционной системе UNIX® файл hosts расположен в директории /etc.
- В операционной системе Windows® файл hosts расположен в директории \Windows\System32\Drivers\etc.
В этой статье предполагается, что все экземпляры облака находятся в одном регионе и, следовательно, имеют частные IP-адреса одной внутренней сети. Если экземпляры облака находятся в разных географических регионах, необходимо решать дополнительные вопросы, связанные с использованием нескольких диапазонов IP-адресов.
Пример: эластичный одноузловой кластер Cognos 8
Помните о том, что всегда проще управлять облачным решением с минимальным количеством образов. Например, несмотря на то, что облако Cognos 8 может содержать экземпляры с различными ролями (шлюз, диспетчер, менеджер управления контентом и т. д.), проще всего управлять развертыванием, создав один общий образ, который в дальнейшем можно настраивать так, как это необходимо.
Кластер Cognos 8 может состоять из трех логических компонентов.
- Шлюз.
- Диспетчер и менеджер управления контентом.
- База данных.
Один из подходов к построению кластера заключается в использовании в облаке трех отдельных программных образов.
- Образ шлюза (с установленными приложениями Cognos и Apache).
- Образ диспетчера.
- Образ базы данных DB2.
При динамическом масштабировании такого решения возникают трудности, которых можно избежать, если поместить все компоненты в один образ, поэтому помните правило: используйте минимальное количество образов.
Можно начать с создания одного образа, включающего в себя все программные компоненты (Cognos 8, Apache и DB2), после чего определить механизм автоматического запуска его экземпляров и настроить их динамическое масштабирование.
Этого можно достичь, выполнив три основных шага.
- Создать один образ со всем необходимым программным обеспечением.
- Настроить кластер с использованием псевдонимов.
- Связать эти псевдонимы с реальными экземплярами и их IP-адресами с помощью файла hosts.
Создайте файл hosts, содержащий следующие значения.
- myCognos. Псевдоним текущего экземпляра (то же самое, что и localhost).
- vm-db2. Псевдоним экземпляра DB2.
- vm-gateway. Псевдоним экземпляра шлюза Cognos.
- vm-cognos1. Псевдоним первого диспетчера Cognos.
- vm-cognos2 ... vm-cognos10. Псевдонимы остальных девяти диспетчеров Cognos.
По умолчанию все псевдонимы, определенные в файле hosts, сопоставлены узлу localhost, т. е. экземпляру текущей машины.
С помощью инструмента Cognos 8 Configuration, расположенного на вкладке Environment, задайте значения в соответствии с таблицей 1.
Таблица 1. Конфигурационные параметры
| URL-адрес шлюза | Замените значение localhost на vm-gateway |
|---|---|
| URI-идентификатор диспетчера | Введите 10 значений: http://vm-cognos1:9080/p2pd/servlet/dispatcher/ext, http://vm-cognos2:9080/p2pd/servlet/dispatcher/ext и так далее для всех десяти диспетчеров. |
| URI-идентификатор контроллера шлюза | Замените значение localhost на myCognos |
| URI-идентификатор внешнего диспетчера | Замените значение localhost на myCognos |
| URI-идентификатор внутреннего диспетчера | Замените значение localhost на myCognos |
| URI-идентификатор для внешних приложений | Замените значение localhost на myCognos |
| Менеджер управления контентом | Введите 10 значений: http://vm-cognos1:9080/p2pd/servlet/dispatcher/ext, http://vm-cognos2:9080/p2pd/servlet/dispatcher/ext и так далее для всех десяти диспетчеров. |
В URI-идентификаторах, приведенных в таблице 1, замените номер порта 9080 (порт по умолчанию, использующийся при установке диспетчера в Websphere® Application Server) на соответствующий номер порта, использующийся в вашей рабочей среде. Например, если вместо WebSphere Application Server вы используете Tomcat, будет задействован порт с номером 9300.
Эти конфигурационные параметры позволяют масштабировать облако от одноузловой топологии до 12-узлового кластера путем простого запуска экземпляров и изменения параметров в файлах hosts.
Теперь давайте рассмотрим кластеры с различным количеством узлов.
Любой экземпляр облака может выступать в роли самостоятельного одноузлового кластера. Все установленное программное обеспечение (Cognos 8, Apache и DB2) запускается на одном экземпляре.
Двухузловой кластер содержит два экземпляра, исполняющие следующие роли.
- Экземпляр 1 исполняет роль СУБД DB2.
- Экземпляр 2 исполняет роль шлюза, диспетчера и менеджера управления контентом.
Назначение роли СУБД DB2 первому экземпляру выполняется путем внесения следующих изменений в соответствующий файл hosts.
| Имя узла в файле hosts первого экземпляра | Новое значение |
|---|---|
| myCognos | IP-адрес экземпляра 1 |
| vm-db2 | IP-адрес экземпляра 1 |
| vm-gateway | IP-адрес экземпляра 2 |
| vm-cognos1 ... vm-cognos10 | IP-адрес экземпляра 2 |
Назначение ролей шлюза, диспетчера и менеджера управления контентом второму экземпляру выполняется путем внесения следующих изменений в соответствующий файл hosts.
| Имя узла в файле hosts второго экземпляра | Новое значение |
|---|---|
| myCognos | IP-адрес экземпляра 2 |
| vm-db2 | IP-адрес экземпляра 1 |
| vm-gateway | IP-адрес экземпляра 2 |
| vm-cognos1 ... vm-cognos10 | IP-адрес экземпляра 2 |
Обратите внимание на то, что все изменения, внесенные в файл hosts, вступают в силу немедленно. При добавлении или изменении записей в файле hosts в большинстве операционных систем (включая Windows и Linux) не требуется перезапускать никакие службы.
Запустите третий экземпляр и измените файлы hosts для назначения следующих ролей.
- Экземпляр 1 исполняет роль СУБД DB2.
- Экземпляр 2 исполняет роль шлюза.
- Экземпляр 3 исполняет роль диспетчера и менеджера управления контентом.
Внесите следующие изменения в файл hosts третьего экземпляра.
| Имя узла в файле hosts третьего экземпляра | Новое значение |
|---|---|
| myCognos | IP-адрес экземпляра 3 |
| vm-db2 | IP-адрес экземпляра 1 |
| vm-gateway | IP-адрес экземпляра 2 |
| vm-cognos1 ... vm-cognos10 | IP-адрес экземпляра 3 |
Переход к кластерам с количеством узлов от 4 до 12
Для добавления в кластер дополнительных узлов повторите вышеописанные шаги. Добавьте новый экземпляр и присоедините его к топологии в качестве дополнительного диспетчера, указав для оставшихся узлов vm-cognos IP-адрес добавляемого экземпляра. Ниже приведен пример изменений в файле hosts четвертого экземпляра
| Имя узла в файле hosts четвертого экземпляра | Новое значение |
|---|---|
| myCognos | IP-адрес экземпляра n |
| vm-db2 | IP-адрес экземпляра 1 |
| vm-gateway | IP-адрес экземпляра 2 |
| vm-cognos1 | IP-адрес экземпляра 3 |
| vm-cognos2 ... vm-cognos10 | IP-адрес экземпляра 4 |
По сути, решение динамически масштабируется путем добавления экземпляров облака в список диспетчеров. Этот список выполняет балансировку нагрузки, позволяя Cognos 8 взаимодействовать с диспетчерами в том порядке, в котором они перечислены в конфигурации Cognos.
В нашем примере мы задали произвольное ограничение на количество диспетчеров (количество диспетчеров – 10, общее количество экземпляров – 12). При необходимости вы можете увеличить или уменьшить их количество.
Сохранение снимков состояния с помощью создания частных образов
Во время развертывания вашего решения не забывайте сохранять снимки состояния экземпляров облака путем создания частных образов. При этом вы не только будете иметь резервные копии, но и сэкономите время в будущем, поскольку все результаты установки и настройки программного обеспечения будут сохранены в образе.
Например, создав частный образ операционной системы с настроенными параметрами безопасности, брандмауэра и прочих системных компонентов, вы получите отправную точку для создания других образов без необходимости каждый раз начинать "с чистого листа". Применение таких снимков базовых образов является рекомендованной метододикой.
Внесение изменений в частные образы приводит к созданию нового частного образа, содержащего только эти изменения. Это означает, что если вы возьмете базовый образ, установите в него, например, Cognos, и затем сохраните, в результате вы получите образ гораздо меньшего размера, который будет содержать лишь вновь добавленное программное обеспечение Cognos 8.
Удалить промежуточные частные образы невозможно, поскольку, как уже говорилось, они содержат лишь изменения, внесенные в предыдущие образы (такие изменения называются дельта-изменениями и предназначены для экономии дискового пространства). Например, если образ В основан на образе Б, который, в свою очередь, основан на образе А, невозможно удалить образ Б, поскольку от него зависит образ В. В облачной среде IBM Cloud образ В генерируется из образа А, к которому применяются изменения, хранящиеся в образе Б.
В облачной среде IBM Cloud файлы могут храниться в двух местах – в файловой системе экземпляра облака либо в смонтированной директории.
Локальная файловая система экземпляра облака аналогична жесткому диску компьютера. Хранящиеся в ней файлы следует рассматривать как временные, поскольку файловая система каждого экземпляра является временной. Если экземпляр будет остановлен (или в нем возникнет ошибка), вся информация, хранящаяся в его файловой системе, будет потеряна. Кроме того, файлы, хранящиеся в экземпляре облака, недоступны другим экземплярам.
Смонтированная директория основана на файловой системе экземпляра IBM Cloud, содержащего хранилище данных. Эта облачная файловая система аналогична сетевому устройству хранения данных (NAS), подключенному к нескольким компьютерам. Благодаря функциям резервирования и обеспечения избыточности среды IBM Smart Business Development and Test Cloud, хранящиеся в ней файлы можно рассматривать как постоянные.
Файлы, хранящиеся в смонтированной директории, могут использоваться совместно всеми экземплярами. Отдельно можно заказать дополнительные сервисы IBM Smart Business Development and Test Cloud, обеспечивающие резервирование и восстановление.
Если файлы необходимо хранить отдельно от образов или если они должны быть доступны для всех экземпляров облака, храните их в смонтированных директориях IBM Storage Cloud. В многоузловой конфигурации Cognos 8 рекомендуется хранить в смонтированных директориях следующие файлы:
- Файловые источники данных.
- Общее программное обеспечение.
- Общие сценарии развертывания (в этом случае можно обновлять/настраивать сценарии без необходимости внесения изменений в приватные образы).
- Заранее сконфигурированные файлы hosts, а также другие конфигурационные файлы, предназначенные для копирования в экземпляры облака.
- Копии важных журналов аудита и регистрации событий (в случае выключения экземпляра эти журналы не потеряются).
- Резервные файлы баз данных.
Мы надеемся, что наши советы помогут вам лучше управлять многоузловыми топологиями облачной среды и эффективно использовать Cognos-решения в облаке IBM Cloud. Совместное использование среды облачных вычислений и мощных инструментов бизнес-анализа поможет усилить конкурентные преимущества ваших приложений.
Для получения дополнительной информации об использовании Cognos в среде облачных вычислений посетите Web-сайт Cognos и портал developerWorks (раздел Ресурсы).
Научиться
-
Оригинал статьи Cognos cloud best practices: Moving from a single- to a multiple-image topology (EN).
-
Дополнительная информация о Cognos Business Analytics (EN).
-
Познакомьтесь с другим программным обеспечением IBM для бизнес-анализа (EN).
-
Команда Cognos Proven Practices предлагает вашему вниманию описание лучших методик, основанных на практическом опыте (EN).
-
В руководстве Redbook "Облако IBM Smart Analytics Cloud" (EN) подробно рассматривается лабораторная реализация облака для задач бизнес-анализа.
-
В разделе облачных вычислений (EN) портала developerWorks вы можете получить информацию и обменяться опытом с разработчиками приложений и служб, ориентированных на работу в среде облачных вычислений.
Получить продукты и технологии
-
Посмотрите онлайновые демонстрационные материалы о программных продуктах Cognos 8 Business Intelligence (EN).
Обсудить
-
Присоединяйтесь к группе облачных вычислений на портале My developerWorks (EN).
-
Следите за блогами по облачным вычислениям на портале My developerWorks (EN).
Стефан Джоу (Stephan Jou) –технический архитектор, штатный научный сотрудник и старший технический сотрудник отделения бизнес-анализа в составе группы технологий и инноваций IBM, расположенной в главном офисе. За время работы над Cognos он разработал и руководил развитием нескольких первых выпусков продукта, в которых были реализованы такие функции как углубленный анализ данных, нейронные сети, визуализация, мобильность, инструментальные панели и семантический поиск. Сейчас его основной задачей в IBM является воплощение научных исследований IBM в стратегию продуктов Cognos и SPSS. Стефан имеет степень магистра естественных наук в области вычислительной нейробиологии и биомедицинской техники, а также двойную степень бакалавра в области вычислительной техники и физиологии человека Университета Торонто.
Уильям Ли (William Lee) – старший инженер-консультант по программному обеспечению IBM Cognos, является сотрудником отделения бизнес-анализа в составе группы технологий и инноваций IBM, расположенной в главном офисе. Он помогает определять технические концепции и направление развития продуктов Cognos и SPSS. Уильям работает над Cognos, начиная с 1992 года. Он имеет степень бакалавра в области вычислительной техники и математики, а также степень магистра вычислительной техники Университета Карлетона в г. Оттава, Канада.
Тан Пхам (Thanh Pham) – разработчик решений IBM в области передовых технологий управления информацией. Его основной задачей является оказание помощи заказчикам в разработке приложений с использованием IBM Mashup Center и облачных вычислений IBM. До этого Тан занимался разработкой решений для ECM/Filenet Business Process Framework.
Бирадж Саха (Biraj Saha) – консультант–разработчик программного обеспечения IBM Cognos, специализирующийся на разработке метаданных и алгоритмов для инструментов моделирования Cognos (таких как Framework Manager, Metrics Designer and Architect), а также на разработке архитектуры SOA и набора SDK для Cognos 8 BI Server. До 2000 года он занимал должность старшего специалиста по разработке программного обеспечения EDS Systemhouse, участвуя в разработке широкого круга приложений реляционных СУБД для заказчиков, в том числе занимался доработкой ERP и СУБД систем, а также написанием собственных приложений на Java™, C++ и 4GL. Бираж имеет степень бакалавра в области вычислительной техники Университета Нью-Брансуик, Канада, а также степень магистра в области вычислительной техники (теория ограничений объектно-ориентированных баз данных) Университета Ватерлоо, Канада.