Перейти к тексту

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

  • Закрыть [x]

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

Вся введенная информация защищена.

  • Закрыть [x]

Лучшие методики облачных вычислений для Cognos: Переход от одноузловой топологии к многоузловой

Проверенные методики управления многоузловыми конфигурациями Cognos в облачной среде

Стефан Джоу, технический архитектор, IBM
Стефан Джоу (Stephan Jou) –технический архитектор, штатный научный сотрудник и старший технический сотрудник отделения бизнес-анализа в составе группы технологий и инноваций IBM, расположенной в главном офисе. За время работы над Cognos он разработал и руководил развитием нескольких первых выпусков продукта, в которых были реализованы такие функции как углубленный анализ данных, нейронные сети, визуализация, мобильность, инструментальные панели и семантический поиск. Сейчас его основной задачей в IBM является воплощение научных исследований IBM в стратегию продуктов Cognos и SPSS. Стефан имеет степень магистра естественных наук в области вычислительной нейробиологии и биомедицинской техники, а также двойную степень бакалавра в области вычислительной техники и физиологии человека Университета Торонто.
Уильям Ли, старший инженер-консультант по программному обеспечению, IBM
Уильям Ли (William Lee) – старший инженер-консультант по программному обеспечению IBM Cognos, является сотрудником отделения бизнес-анализа в составе группы технологий и инноваций IBM, расположенной в главном офисе. Он помогает определять технические концепции и направление развития продуктов Cognos и SPSS. Уильям работает над Cognos, начиная с 1992 года. Он имеет степень бакалавра в области вычислительной техники и математики, а также степень магистра вычислительной техники Университета Карлетона в г. Оттава, Канада.
Пхам Тан, архитектор решений, IBM
Тан Пхам (Thanh Pham) – разработчик решений IBM в области передовых технологий управления информацией. Его основной задачей является оказание помощи заказчикам в разработке приложений с использованием IBM Mashup Center и облачных вычислений IBM. До этого Тан занимался разработкой решений для ECM/Filenet Business Process Framework.
Бирадж Саха, консультант–разработчик программного обеспечения, IBM
Бирадж Саха (Biraj Saha) – консультант–разработчик программного обеспечения IBM Cognos, специализирующийся на разработке метаданных и алгоритмов для инструментов моделирования Cognos (таких как Framework Manager, Metrics Designer and Architect), а также на разработке архитектуры SOA и набора SDK для Cognos 8 BI Server. До 2000 года он занимал должность старшего специалиста по разработке программного обеспечения EDS Systemhouse, участвуя в разработке широкого круга приложений реляционных СУБД для заказчиков, в том числе занимался доработкой ERP и СУБД систем, а также написанием собственных приложений на Java™, C++ и 4GL. Бираж имеет степень бакалавра в области вычислительной техники Университета Нью-Брансуик, Канада, а также степень магистра в области вычислительной техники (теория ограничений объектно-ориентированных баз данных) Университета Ватерлоо, Канада.

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

Больше статей из этой серии

Дата:  21.06.2011
Уровень сложности:  средний PDF:  A4 and Letter (45 КБ | 13 страница)Загрузить Adobe® Reader®
Активность:  1150 просмотров
Комментарии:  


Как и при проектировании традиционного центра обработки данных, при развертывании 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 состоит из четырех основных проблемно-ориентированных компонентов.

  1. IBM Cognos 8 BI Reporting – единое Web-решение, предназначенное для формирования отчетов и работы с ними на протяжении всего жизненного цикла и обладающий следующими возможностями:
    • Получение отчетов в режиме самообслуживания, позволяющие пользователям получать требуемую информацию без привлечения ИТ-специалистов.
    • Подход "написать один раз, использовать везде", позволяющий ИТ-специалистам создавать отчеты, доступные пользователям большого числа различных устройств. Поддерживаются более 25 языков, несколько различных форматов, а также доступ из других приложений и процессов.
  2. IBM Cognos 8 BI Analysis – компонент, позволяющий работать с информацией в интерактивном режиме независимо от того, где она хранится (аналитическая обработка в реальном времени и многомерные реляционные источники). Cognos 8 BI Analysis позволяет быстро выполнять сложный анализ, переходить от уровня обобщений к уровню детальных транзакций для получения необходимой информации, а также содержит встроенные настраиваемые временные ряды, с помощью которых можно выявлять и детально исследовать тенденции изменений, происходивших в компании за предшествующие периоды времени.
  3. IBM Cognos 8 BI Dashboards – компонент, предназначенный для мониторинга, оценки и управления эффективностью предприятия и позволяющий получать наглядные сводные представления данных из различных источников. Cognos 8 BI Dashboards является ключевым инструментом анализа, позволяющим предотвращать возникновение проблем на самой начальной стадии. Информационные панели позволяют создавать любые графические представления данных и просматривать результаты в различных форматах.
  4. 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.

С чего начать работу с облаком

При проектировании и модернизации вашей конфигурации придерживайтесь следующих правил.

  1. Начните с простого. Обеспечьте соблющение необходимых требований, но не усложняйте конфигурацию без лишней необходимости.
  2. В конфигурации вашего облака всегда должно присутствовать минимально необходимое количество экземпляров. Добавить дополнительные экземпляры очень легко, поэтому можно уменьшить начальные требования.
  3. Второй пункт также относится к количеству уникальных образов в облаке. Например, всегда проще управлять одним образом самонастраиваемой базы данных DB2, чем создавать пять различных образов СУБД.
  4. Процесс проектирования и тестирования вашей конфигурации должен быть итерационным. Например, рабочий цикл может иметь следующий вид.
    1. Проектирование/модернизация конфигурации.
    2. Создание/подготовка необходимых экземпляров.
    3. Установка/настройка экземпляров.
    4. Сохранение снимков состояния образов.
    5. Проверка функциональности системы и оценка ее производительности.
    6. Повторение всех шагов.

Теперь давайте перейдем к главной части статьи – проверенным методикам управления многоузловыми конфигурациями 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), после чего определить механизм автоматического запуска его экземпляров и настроить их динамическое масштабирование.

Этого можно достичь, выполнив три основных шага.

  1. Создать один образ со всем необходимым программным обеспечением.
  2. Настроить кластер с использованием псевдонимов.
  3. Связать эти псевдонимы с реальными экземплярами и их 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 первого экземпляраНовое значение
myCognosIP-адрес экземпляра 1
vm-db2IP-адрес экземпляра 1
vm-gatewayIP-адрес экземпляра 2
vm-cognos1 ... vm-cognos10IP-адрес экземпляра 2

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

Имя узла в файле hosts второго экземпляраНовое значение
myCognosIP-адрес экземпляра 2
vm-db2IP-адрес экземпляра 1
vm-gatewayIP-адрес экземпляра 2
vm-cognos1 ... vm-cognos10IP-адрес экземпляра 2

Обратите внимание на то, что все изменения, внесенные в файл hosts, вступают в силу немедленно. При добавлении или изменении записей в файле hosts в большинстве операционных систем (включая Windows и Linux) не требуется перезапускать никакие службы.

Кластер с тремя узлами

Запустите третий экземпляр и измените файлы hosts для назначения следующих ролей.

  • Экземпляр 1 исполняет роль СУБД DB2.
  • Экземпляр 2 исполняет роль шлюза.
  • Экземпляр 3 исполняет роль диспетчера и менеджера управления контентом.

Внесите следующие изменения в файл hosts третьего экземпляра.

Имя узла в файле hosts третьего экземпляраНовое значение
myCognosIP-адрес экземпляра 3
vm-db2IP-адрес экземпляра 1
vm-gatewayIP-адрес экземпляра 2
vm-cognos1 ... vm-cognos10IP-адрес экземпляра 3

Переход к кластерам с количеством узлов от 4 до 12

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

Имя узла в файле hosts четвертого экземпляраНовое значение
myCognosIP-адрес экземпляра n
vm-db2IP-адрес экземпляра 1
vm-gatewayIP-адрес экземпляра 2
vm-cognos1IP-адрес экземпляра 3
vm-cognos2 ... vm-cognos10IP-адрес экземпляра 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 (раздел Ресурсы).


Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Об авторах

Стефан Джоу (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. Бираж имеет степень бакалавра в области вычислительной техники Университета Нью-Брансуик, Канада, а также степень магистра в области вычислительной техники (теория ограничений объектно-ориентированных баз данных) Университета Ватерлоо, Канада.

Помощь по сообщениям о нарушениях

Сообщение о нарушениях

Спасибо. Эта запись была помечена для модератора.


Помощь по сообщениям о нарушениях

Сообщение о нарушениях

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.


developerWorks: вход


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Выберите ваше отображаемое имя

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

(Должно содержать от 3 до 31 символа.)


Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Оценить эту статью

Комментарии

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=681855
ArticleTitle=Лучшие методики облачных вычислений для Cognos: Переход от одноузловой топологии к многоузловой
publish-date=06212011
author1-email=Stephan.Jou@ca.ibm.com
author1-email-cc=
author2-email=William.Lee@ca.ibm.com
author2-email-cc=
author3-email=thanhp@us.ibm.com
author3-email-cc=
author4-email=Biraj.Saha@ca.ibm.com
author4-email-cc=

Теги

Help
Используйте форму поиска, чтобы найти любой контент с данным тегом в My developerWorks. Используйте ползунок, чтобы отразить больше или меньше тегов.

КнопкаПопулярные теги отображает самые распространенные теги для данной области контента (например: Java, Linux, WebSphere).

Кнопка Мои теги отображает Ваши теги для данной области контента (например: Java, Linux, WebSphere).

Используйте форму поиска, чтобы найти любой контент с данным тегом в My developerWorks. Кнопка Популярные теги отображает самые распространенные теги для данной области контента (например: Java, Linux, WebSphere). Кнопка Мои теги отображает Ваши теги для данной области контента (например: Java, Linux, WebSphere).