Всем привет сегодня хочу рассказать как настроить систему хранения данных IBM Storwize v3700. Самая элементарная схема:

  • СХД IBM Storwize v3700 в базовой комплектации с возможностью подключения серверов по iSCSI и SAS. Установлены 4 диска по 600Gb
  • два сервера IBM 3650 m4, без локальных дисков, с двумя однопортовыми SAS HBA картами
  • подключение крест на крест, отказоустойчивое - каждый HBA адаптер сервера соединен со своим контроллером системы хранения

Задача стоит следующая:

  1. Подключиться к СХД для управления
  2. Обновить прошивку, чтобы появилась поддержка SAS подключений
  3. Создать из дисков array, уровень RAID 10
  4. Так как у нас серверы без жестких дисков, создаем для каждого сервера отдельный LUN для установки операционной системы Windows server 2012
  5. Создаем один общий LUN, который будет доступен обоим серверам. Использоваться он будет для создания MS SQL 2012 кластера, точнее для хранения баз данных

В состав поставки системы хранения есть специальная флешка, она используется для первоначального конфигурирования, а именно установка пароля администратора, сервисного IP адреса для подключения к веб интерфейсу. С флешки на компьютере запускаем утилиту InitTool.bat

Так как мы только что достали СХД из коробки, выбираем пункт Create a new system

Задаем IP адрес, по которому будем подключаться к системе хранения

Процесс инициализации системы:

  1. Делаем безопасное извлечение устройства из компьютера, достаем флешку.
  2. Смотрим на один из контроллеров системы хранения. Нам нужно будет вставить флешку в один из разъемов с сетевыми интерфейсами управления. Но перед этим нужно убедиться, что с правой верхней стороны контроллера три световых индикатора подают верные семафорные сигналы, левый горит, средний мигает, правый выключен.
  3. После того, как флешка будет помещена в USB порт (любой). Начинает мигать правый значок (восклицательный). Необходимо дождаться пока он перестанет потухнет, после этого можно извлечь флешку и вернуть ее обратно в компьютер, чтобы закончить шаги мастера.

Через браузер (рекомендуется IE8 или Firefox 23+) заходим на веб интерфейс. По умолчанию логин пароль для входа IBM Storwize v3700 superuser - passw0rd (через ноль)
Теперь самое время обновить прошивку, для этого переходим в меню Settings -> General -> Upgrade Machine Code. Прошивка заранее скачана с официального сайта ibm.com. В нашем случае это Version 7.1.0.3 (build 80.3.1308121000). В ее составе есть Upgrade test utility, сначала загружаем на СХД ее, а затем саму прошивку.

СХД автоматически определила 4 установленных диска. Три из них система отдала под POOL, один назначила под hot spare. Если бы дисков было больше, может быть имело бы смысл оставить подобную автоматическую настройку. В нашем случае лучше переразбить диски по-другому.

Удаляем автоматически созданный Pool, Delete.

Получаем 4 свободных диска, из которых предстоит создать RAID 10

Нажимаем Configure Storage, затем выбираем какой именно RAID мы хотим создать и сколько дисков будет задействовано под него.

Задаем название для вновь создаваемого Pool. Чтобы не запутаться в терминах. Из свободных дисков мы создаем RAID или array, получившееся свободное пространство это Pool. Затем само пространство пула будем нарезать на кусочки, так называемые LUN-ы или Volume и вот их уже можно будет презентовать серверам (хостам).

Pool создался

Создаем новый LUN (тут он называется Volume) в нашем пуле, Выбираем Generic-Create

задаем размер Volume

Таким образом, используя мастер создания Volume-ов делаем 3 луна. Как и было задумано, два по 100Gb под операционные системы серверов. И один общий размером 500Gb для создания кластера MS SQL 2012

Теперь необходимо сообщить системе хранения данных, какие серверы (host) к ней подключены. В базовой комплектации всего два варианта соединения - это iSCSI и SAS. У нас два сервера, которые подключены к Storwize v3700 по SAS

На этом шаге мы указываем системе хранения, что наш первый сервер подключен к ней двумя SAS кабелями, которые в сервере воткнуты в две SAS HBA карты со идентификаторами (16-ти значные). Таким образом добавляем оба сервера, у каждого два идентификатора.

Презентуем Volume-ы серверам. Другими словами назначаем права доступа. На скриншоте HOST_LUN_TOP предназначен только для первого сервера, т.к. на него будет установлена его операционная система. И второму серверу этот LUN видеть нельзя. В отличии от SQL_LUN, который должен быть доступен обоим серверам, ведь на нем будут располагаться базы данных MS SQL кластера.

В любой момент можно посмотреть и изменить права доступа на LUN (Host Mapping)

На этом настройку СХД можно считать законченной. Можно на сервере начинать установку Windows server 2012 R2 и при выборе жесткого диска будут доступны два LUN-а с системы хранения, один размером 100Гб, второй 500Гб. Это будет означать, что настройка прошла успешно.

Вот так вот производится ibm storwize v3700 настройка, далее я расскажу как производится ibm storwize v3700 мониторинг производительности.

Для настройки и дальнейшего управления системами хранения дынных серии DS35xx от IBM используется программа DS storage manager, последнюю версию которой можно скачать с официального сайта, конечно, после регистрации. Есть версии программы для разных операционных систем, Linux, Windows, Mac, HPUX

Здесь же, не лишним будет скачать последние обновления прошивки контроллеров системы хранения. Иначе СХД может не увидеть дисков или HBA адаптеры в серверах или возникнут другие сопутствующие проблемы.

Не знаю почему, но у многих возникают проблемы с поиском и скачиванием на сайте IBM файлов для загрузки. Заходим на Ibm.com -> Support and Downloads -> Fixes, updates and drivers -> Quick find-> в строке поиска "DS3500 (DS3512, DS3524)" -> View DS3500 (DS3512,DS3524) downloads. Портал IBM не всегда корректно отрабатывает, поэтому если не получается, попробуйте другой браузер.

Прошивки на контроллер, выглядят так

Файлы для загрузки DS storage manager, так



После установки и запуска программы, предлагается выбрать метод нахождения СХД. Automatic сканирует сеть и ищет подключенную DS35xx, в Manual нужно вручную ввести IP адреса обоих контроллеров нашей СХД. Адреса интерфейсов управления, которые заданы по умолчанию, для удобства написаны на самой системе хранения под портами. Если в сети работает DHCP, то адреса будут получены автоматически.



Мы видим, что для отказоустойчивости в каждый контроллер встроены по два порта управления, но, обычно, для управления используются первые порты каждого контроллера.


Схема подключения

Перед началом настройки нужно представлять, что хотим получить в итоге, если понимания нет, то и начинать не стоит. Сделаем самую простую схему, подключим к системе хранения два сервера по схеме.


В каждом сервере два SAS HBA адаптера, для тех кто не знает, это просто карта PCI-E, с входом SAS. По два HBA установлено для отказоустойчивости, если один из контроллеров в СХД выйдет из строя, то работа будет продолжена через другой. По такой же логике система защищена от проблем с SAS кабелем или HBA адаптером в сервере.

Настройка. Логика.

У нас есть СХД, в ней диски. Сначала нам нужно из дисков собрать какой-нибудь RAID (array), потом на этом RAID создать логический том (LUN), затем презентовать этот том серверам (mapping), чтобы они его увидели и могли с ним работать. Вот такая логика.

Теперь по порядку. Я буду совершать все манипуляции в симуляторе, скачать который можно на официальном сайте хранилищ IBM. Интерфейс не один в один повторяет то, что вы увидите на реальной DS3524 или DS3512
1.. Мы ранее выбрали автоматический метод поиска системы хранения, система нашла и подключила ее, СХД отображается в консоли.

2.. Кликаем правой кнопкой по СХД, выбираем пункт Manage, чтобы начать настройку.

3.. В новом окне открывается мастер, но т.к. я хочу показать универсальную последовательность действий, закрываем его.

4.. В закладке Logical/Physical View видим нераспределенное дисковое пространство. В симуляционной СХД диски двух типов, мы настроим привычные SATA. Сначала создаем Array (RAID)



6.. Задаем ИМЯ нашему array


7.. Выбираем, какой именно RAID мы хотим получить. Не видим 10 RAID, чтобы его создать нужно выбрать RAID 1
8.. И тут же мастер объясняет, что если вы создаете RAID 1 из четырех и более дисков, то автоматически создастся 10 RAID (или 1+0, то же самое)
9.. Выбираем создание RAID из 38 дисков

10.. После создания, автоматически запускается мастер создания тома (LUN), его также можно запустить и из консоли, как в 4-ом шаге, только выбирать надо созданный ранее array.

11.. Нужно указать размер LUN, в моем случае 8 Tb (всего свободно 17,6 Tb), и придумать название для тома
12.. Важный момент, если мы знаем, какая ОС будет установлена в этот LUN то нужно указать ее. Для VMware тоже есть строчка, для XenServer выбирается Linux. А у меня в симуляторе почему-то этих строчек нет
13.. После создания Array и LUN мы их видим в консоли
14.. Теперь необходимо перейти на другую вкладку и дать доступ к этому LUN серверу. Видим, что по умолчанию создана группа Default Group и этой группе доступен LUN1. Нам достаточно добавить наш сервер (сначала один, затем другой) в это группу, чтобы они могли подключиться к LUN1.

15.. Кликаем правой кнопкой мыши по Default Group, Define -> Host

16.. У каждого нашего сервера есть по два SAS HBA, именно через них происходи подключение к СХД. Система хранения может идентифицировать сервер именно по HBA адаптерам, а точнее, по их уникальным «identifier».

Задаем имя хосту (у меня ESX1). Выбираем два «identifier», которые принадлежат серверу, который мы подключаем. Посмотреть, какие идентификаторы у сервера, можно подключившись к ESXi хосту напрямую через vSphere Client или через vCenter Server. Там в искать разделе «storage adapters».

Переносим два «identifier» из левой колонки в правую. Затем выбираем каждый «identifier» и жмем на кнопку Edit, чтобы добавить и к нему описание. Такая процедура придумана для того, чтобы не запутаться в большом количестве идентификаторов.

У меня в симуляторе, какие-то нули вместо уникальных «identifier», не обращайте внимания, у вас все будет как положено.

17.. Теперь выбираем операционную систему хоста, если VMware то выбираем VMware

18.. После этого в консоли вы увидите свой Host и из-за того что он находится в группе Default Group, ему будет доступен LUN1.

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

Чуть сложнее настраивается подключение по iSCSI. Советую выбирать или SAS или FC.

В данной статье, мы рассмотрим вопрос установки и настройки на CentOS 7 . В данном мануале, будет продемонстрирована установка trial версии WebSphere , но она ничем не отличается от полной версии, так что это не имеет значения.

Итак, поехали!

1) Подготовка и настройка ОС

В нашей работе мы будем использовать новую CentOS 7 . На удивление, но “из коробки” ее нужно нехило так допилить до рабочего состояния, так что будьте к этому готовы. Итак, устанавливаем минимальную версию без графики и поехали. Через интерфейс – настройте сразу сеть, чтобы был интернет… это значительно облегчит вашу участь:)

Установим базовое ПО… которого почему-то нет в поставке:

Yum install net-tools nano wget

Теперь проверим наш hostname и поправим hosts (поправьте как вам нравится):

Nano /etc/hostname nano /etc/hosts

Ifconfig -a

Чтобы это исправить, надо сначала поправить немного grub :

Nano /etc/default/grub

В конце строки “GRUB_CMDLINE_LINUX ” нужно добавить “net.ifnames=0 biosdevname=0 “. Получится что-то типа такого (не обязательно 1 в 1):

GRUB_CMDLINE_LINUX="rd.lvm.lv=rootvg/usrlv rd.lvm.lv=rootvg/swaplv crashkernel=auto vconsole.keymap=usrd.lvm.lv=rootvg/rootlv vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0 "

Переименовываем наш сетевой интерфейс на нормальный, классический “eth0 ” и ребутимся:

Mv /etc/sysconfig/network-scripts/ifcfg-ens32 /etc/sysconfig/network-scripts/ifcfg-eth0 reboot

Настраиваем сеть:

Nano /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" ONBOOT=yes BOOTPROTO=static IPADDR=1.1.4.185 NETMASK=255.255.248.0 GATEWAY=1.1.1.9 DNS1=1.1.1.10 DNS2=1.1.1.90

Отключаем лишний Network manager и ребутимся:

Systemctl stop NetworkManager systemctl disable NetworkManager reboot

Проверяем, обозначен ли в системе как-нить IPv6 :

Lsmod | grep -i ipv6

Если сообщения будет иметь упоминания об IPv6 , а оно будет, то переходим к его отключению:

Nano /etc/default/grub

В начале строки “GRUB_CMDLINE_LINUX ” нужно добавить “ipv6.disable=1 “. Получится что-то типа такого:

GRUB_CMDLINE_LINUX="ipv6.disable=1 rd.lvm.lv=rootvg/usrlv...

Создаем новый конфиг и сохраняем результат:

Grub2-mkconfig -o /boot/grub2/grub.cfg

Перезагружаемся:

Проверяем еще раз и убеждаемся, что все красиво:

Lsmod | grep -i ipv6

Добавляем в систему EPEL (всякие “отягощенные” лицензиями пакеты) репозиторий для CentOS 7 :

Wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm rpm -ivh epel-release-7-2.noarch.rpm yum repolist

Новая ОС использует “главного” демона, управляющего другими демонами. Это systemd , который ввели вместо устаревших скриптов инициализации init.d . Также используется новый фаервол, firewalld вместо iptables . Проверим его работу и откроем нужные нам порты (9080 и 9443):

Systemctl status firewalld firewall-cmd --permanent --zone=public --add-port=9080/tcp firewall-cmd --permanent --zone=public --add-port=9443/tcp systemctl restart firewalld

Собственно говоря, на этом настройка ОС заканчивается и мы переходим непосредственно к установке IBM WebSphere Application Server Liberty Profile 8.5.5

2) Установка WebSphere

Нам потребуется учетная запись IBM . После обычной регистрации можно скачать любое ПО (в целях разработки, оно еще называется trial version ).

Напрямую ПО скачивать не дают. Мы скачиваем универсальный Installation Manager , и потом уже через него мы сможем скачать нужное нам ПО. Содержимое архива BASETRIAL.agent.installer.linux.gtk.x86_64.zip распаковываем в папку was и ее же потом закачиваем на сервер в /root

Даем права и запускаем установку:

Chmod -R 775 /root/was cd was ./installc -c

Первым делом, Installation Manager попросит нас ввести наш логин и пароль от учетки IBM. Нажимаем p и вводим учетные данные:

Выбираем для установки только следующие пункты (installation manager, websphere liberty и java sdk для нее):

А вот фиксы ставить не будем. Они не обязательные к установке, к тому же баганутые и устанавливаются с ошибкой:

Итоговое сообщение. Что и куда устанавливается:

После этого – ждем. Сколько ждать? Зависит от скорости вашего Интернета и загруженности серверов IBM . Необходимо будет скачать около 500 мб, а то и больше. Запаситесь терпением… Что происходит? Инсталлятор подключает свои репозитории и скачивает с него заказанное ПО. Все красиво.

Сообщение об успешной установке выглядит так:

Теоретически, возможна также установка всего этого через response files, без диалогов. Но этот вариант также требует уже установленного Installation Manager , так что в нашем случае это не актуально..

Итак, все! мы установили IBM WebSphere Application Server Liberty Profile 8.5.5 и необходимую для его работы Java ! Поздравляю! Сейчас мы рассмотрим, что можно сделать дальше.

3) Настройка WebSphere

а) Запуск WebSphere

Давайте создадим наш тестовый сервер:

/opt/IBM/WebSphere/Liberty/bin/server create PROJECT

Создали. Появилась папка: /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT Все настройки и будущие модули, будут находится именно в ней. Чтобы запустить данный СП, надо добавить в главный его конфиг строку host=’1.1.4.185′ (с нашим IP), над httpPort=’9080′ (это тут: /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT/server.xml ). Пример такого конфига:

Запускаем:

/opt/IBM/WebSphere/Liberty/bin/server start PROJECT

Перейдя по адресу http://1.1.4.185:9080 , увидим следующее:

Это значит, что все хорошо и вебсфера запустилась.

б) Установка модуля администрирования

Этот пункт не является обязательным. Но с модулем администрирования работать с вебсферой удобнее. Через него, можно останавливать и запускать модули по отдельности, без необходимости остановки всего сервера.

Итак, устанавливаем этот модуль:

/opt/IBM/WebSphere/Liberty/bin/featureManager install adminCenter-1.0 --when-file-exists=ignore

Для входа в админку под админом, используем учетную запись: admin/password. А под пользователем: nonadmin/nonadminpwd.

Адрес входа на нее: http://1.1.4.185:9080/adminCenter/ Выглядит админка так:



Все! Модуль администрирования установлен.

в) Установка модуля расширений

Также, на Вебсферу нужно установить extended пакеты (расширенный набор библиотек и бинарников), делается это предельно просто:

/opt/IBM/WebSphere/Liberty/bin/featureManager install extendedPackage-1.0

г) Установка модулей

Мы подошли к самому интересному. Установка модулей в Liberty. Как же это сделать? Есть 2 способа, через папку /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT/dropins и /opt/IBM/WebSphere/Liberty/usr/servers/PROJECT/apps
Из каталога dropins модули подхватываются и устанавливаются автоматически. Из каталога apps – их нужно вручную прописать в конфиге server.xml. Пример конфига, к котором подключается модуль через apps:

Для запуска СП не в фоне и с логами, выполните команду:

/opt/IBM/WebSphere/Liberty/bin/server run PROJECT

д) Плюсы

Тестированием проверено, что достаточно скопировать папку /opt/IBM на другой сервер и все будет работать из коробки. Очень удобно. Т.е. мы можем заранее настроить нужный нам СП и делать поставки целого пакета ПО сразу. А еще “вебсфера либерти” очень легкая и запускается/останавливается очень шустро:)

Опубликовано

Кластеры позволяют масштабировать конфигурацию IBM® WebSphere Portal . Кроме того, кластеры обеспечивают высокую готовность приложений J2EE, поскольку в случае сбоя запросы автоматически пересылаются на исправные серверы. Кластер можно настроить различными способами: горизонтальный, вертикальный, множественный и динамический.

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

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

В ответ на пожелания пользователей приведены инструкции по настройке WebSphere Portal для каждой операционной системы. Выберите операционную систему, чтобы начать процесс.

  1. Подготовка операционной системы IBM i в кластерной среде
    См. информацию по настройке операционной системы для работы с IBM WebSphere Portal . В случае установки других компонентов могут потребоваться дополнительные действия; ознакомьтесь с документацией по этим компонентам.
  2. Подготовка основного узла в IBM i
    Перед созданием кластерной среды вы должны установить IBM WebSphere Portal на основном узле и затем настроить базу данных и администратор сетевого развертывания.
  3. Создание и дополнение нового профайла Администратора развертывания в IBM i
    В рабочей среде Администратор развертывания должен быть установлен на удаленном сервере, а не на одном сервере с IBM WebSphere Portal . Для создания удаленного профайла Администратора развертывания воспользуйтесь Инструментом управления профайлами или командой manageprofiles . В среде тестирования или разработки Администратор развертывания можно установить в локальной системе с помощью IBM Installation Manager . В случае установки удаленного профайла Администратора развертывания выполните действия по созданию профайла Администратора развертывания и его дополнению. Пропустите эти шаги, если локальный профайл Администратора развертывания устанавливается с помощью Installation Manager на основном узле.
  4. Создание кластера в IBM i
    После установки IBM WebSphere Portal на основном узле, настройки удаленной базы данных и подготовки основного узла к взаимодействию с Администратором развертывания можно создать статический кластер для обработки запросов переключения.
  5. Подготовка веб-сервера, когда портал установлен в IBM i в кластерной среде
    Установите и настройте модуль веб-сервера, предоставляемый IBM WebSphere Application Server , для настройки веб-сервера для взаимодействия с IBM WebSphere Portal .
  6. Кластер IBM i: Подготовка реестров пользователей
    Установите и настройте сервер LDAP в качестве реестра пользователей, предназначенного для хранения информации о пользователях и идентификации пользователей в рабочей среде с кластерами.

  7. Настройте защиту реестра пользователей в IBM WebSphere Portal , чтобы защитить сервер от несанкционированного доступа. Можно настроить автономный реестр пользователей LDAP или добавить реестры пользователей LDAP или База данных в объединенное хранилище по умолчанию. После настройки реестра пользователей вы можете добавить области для виртуальных порталов или вспомогательную базу данных для хранения атрибутов, которые нельзя хранить в реестре пользователей LDAP.
  8. Подготовка дополнительных элементов кластера в IBM i
    После установки и настройки основного узла вы можете создать дополнительные узлы. Вы можете установить IBM WebSphere Portal на каждом узле и затем настроить узел для доступа к базе данных и реестру пользователей, прежде чем добавлять его в кластер.
  9. Кластер IBM i: Тонкая настройка серверов
    Тонкая настройка серверов играет важную роль в обеспечении требуемой производительности среды WebSphere Portal. Изначально WebSphere Portal не настроен для рабочей среды, поэтому для обеспечения оптимальной производительности просмотрите и выполните процедуры из руководства IBM WebSphere Portal Tuning Guide. Если руководство по тонкой настройке для текущего выпуска WebSphere Portal отсутствует, воспользуйтесь руководством для предыдущего выпуска.
  10. Настройка поиска в кластере IBM i
    IBM WebSphere Portal предоставляет две различные возможности поиска. Можно использовать обе возможности поиска в кластерной среде.
  11. Настройка нескольких кластеров в IBM i
    Дополнительные кластеры ячейки создаются практически так же, как первый, за некоторыми исключениями. Фактически, новый профайл будет предназначен для использования в качестве основного профайла, согласно терминологии кластеров IBM WebSphere Portal , и будет взят за основу для нового определения кластера. Это копирует процесс создания первого кластера в ячейке. Во время процесса распространения при наличии каких-либо приложений в этом новом узле в ячейке (так как они используются первым кластером) Администратор развертывания не позволит добавить их. После распространения приложения, уже существующие в ячейке, не отображаются на сервер WebSphere_Portal на вновь добавленном узле; таким образом, существующие приложения следует заново привязать к новому распространенному серверу для восстановления списка приложений. Таким образом, в зависимости от конфигурации нового профайла, некоторые приложения будут использоваться совместно прочими существующими кластерами, а некоторые - уникальными для этого нового профайла.
  12. Совместное использование доменов базы данных между кластерами в IBM i
    Если рабочая среда состоит из нескольких кластеров в одной ячейке и нескольких кластеров в разных ячейках, то для поддержки избыточности и восстановления после сбоя можно предоставить доступ к доменам базы данных всем кластерам. Данные IBM WebSphere Portal хранятся в нескольких доменах базы данных с различными требованиями к уровню готовности, зависящими от конфигурации рабочей среды. При наличии нескольких технологических линий, каждая из которых реализована в виде кластера серверов, применение общих доменов базы данных гарантирует автоматическую синхронизацию данных между технологическими линиями.

а значит можно применять на практике и полнофункциональную версию DB2 10.1.

Если сравнивать бесплатные версии DB2 Express-C 9.7 и 10, то очевидно преимущество - теперь объем используемой оперативной памяти увеличен с 2 до 4 Гб , что не может не радовать.

Скачать бесплатную и демонстрационную коммерческую версию возможно здесь - http://www-01.ibm.com/software/data/db2/linux-unix-windows/download.html (для скачивания потребуется IBM ID, но регистрация быстрая и бесплатная).

Посмотрим, как выглядит процесс установки и настройки на примере бесплатной версии.

Скачиваем дистрибутив, распаковываем его и запускаем файл setup.exe, появляется приветственное окно.

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

Начало установки

Принимаем лицензионное соглашение

Оставляем обычную установку и продолжаем. Для 1С этого будет достаточно.

Если вы хотите установить DB2 только на один компьютер - файл ответов можно не создавать

Указываем каталог установки. Если у вас выделен отдельный дисковый массив на базы DB2 - можно выполнять установку сразу туда, это позволит по умолчанию создавать новые базы на том же диске, но параметр, отвечающий за это, можно всегда поменять.

От SSH я отказался. Это дополнительная возможность администрирования сервера, которую желательно использовать при управлении серверами через публичные сети по незащищенному каналу. В локальной сети особого смысла от этого нет.

Создаем новую учетную запись для запуска процессов сервера

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

Ждем завершения установки и видим сообщение об успехе

Сразу после окончания установки добавляем важный параметр, который позволит оптимизировать работу DB2 для 1С:

Открываем командное окно

И выполняем команду
db2set DB2_WORKLOAD=1C
если запустить просто db2set, то система покажет список установленных параметров

Затем перезапускаем СУБД:
db2stop
db2start

Создаем новую информационную базу в 1С, при этом в качестве пользователя сервера БД необходимо указать db2admin, которого вы создали в процессе установки

Не забываем проверить, что в каталоге с сервером приложений 1С размещен файл-семафор db2loadapion , что позволит ускорить процесс загрузки базы данных из dt-файла.

На этом все. Осталось загрузить в созданную базу dt-файла или файл конфигурации и работу можно начинать.

"Центра управления" в DB2 10.1 больше нет, но, кроме командной строки можно установить бесплатный инструмент для администрирования DB2 - IBM Data Studio.