Записки Oracle-ойда Голосов: 1 Адрес блога: http://stan1slav.blogspot.com/ Добавлен: 2011-07-16 14:20:30 блограйдером stan1slav Принадлежит блограйдеру stan1slav

Клонирование Oracle Fusion Middleware 11g

2012-03-15 09:43:00 (читать в оригинале)

Клонирование Oracle Fusion Middleware 11g (SOA Suite, ODI, IDM, Webcenter и т.д.) условно можно разделить на две логические части:

• Клонирование Middleware Home;
• Клонирование доменов.

Существует несколько ограничений по клонированию:

• окружения должны быть идентичными, т.к. сервер назначения и сервер источник должны иметь одну и ту же операционную систему и разрядность (32 или 64);
• система назначения и система источник должны иметь одного и того же административного пользователя (например, weblogic), но пароли могут быть различны. После завершения клонирования можно изменить пользователя.

Клонирование СУБД и других внешних систем, которые используются в приложениях/композитах выходят за рамки данной статьи.

Клонирование Middleware Home

Типовая структура Middleware Home (MW_HOME):

1. Останавливаем все сервера (AdminServer и ManagedServer-а) всех доменов (на источнике), которые используют клонируемый Middleware Home;
2. На источнике перейти в директорию:
   

    $ cd $MW_HOME/oracle_common/bin/  

3. Затем выполнить команду:
   

    $ ./copyBinary.sh -javaHome /opt/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/ 
   -archiveLoc /tmp/mw_copy.jar -sourceMWHomeLoc /opt/Middleware/

   где javaHome – директория c JDK;
         archiveLoc – имя файла для экспорта;
         sourceMWHomeLoc – директория в которой развернут MW_HOME.


4. Скопировать файл экспорта с сервера источника на сервер назначения. А так же следующие файлы:
   

    $ ls $MW_HOME/oracle_common/bin/pasteBinary.sh  
    $ ls $MW_HOME/oracle_common/jlib/cloningclient.jar  
   



5. Запускаем импорт Middleware Home на сервере назначения:
   

    $ ./pasteBinary.sh -javaHome /u01/jdk1.6.0_30/ 
   -archiveLoc mw_copy.jar -targetMWHomeLoc /u01/ofm  
   

   где javaHome – директория c JDK;
         archiveLoc – имя файла для импорта;
         targetMWHomeLoc – директория в которой будет развернут MW_HOME.
   

Клонирование доменов

1. Проверяем, что все сервера домена (на источнике) для клонирования стартованы.
2. Если в домене есть machine типа Unix Machine, то необходимо изменить её на тип Machine. Для этого необходимо:
   

    $ cp $DOMAIN_HOME/config/config.xml $DOMAIN_HOME/config/config.xml.bkp  
    $ vi $DOMAIN_HOME/config/config.xml  
   

   Далее найти следующую строку (или строки если несколько машин):
   

    <machine xsi:type="unix-machineType">  
   

   И заменить её (или их) на:
   

    <machine>  
   

   После этого перезапустить AdminServer.
   
3. На сервере источнике перейти в директорию:
   

    $ cd $MW_HOME/oracle_common/bin/  
   

4. Затем выполнить на источнике команду:
   

    $ ./copyConfig.sh -javaHome /opt/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/  
                   -archiveLoc /tmp/soa_domain.jar 
                   -sourceDomainLoc /opt/user_projects/domains/soa_domain/     
                   -sourceMWHomeLoc /opt/Middleware/                         
                   -domainHostName oracle-sb.tsretail.ru    
                   -domainPortNum 9000 
                   -domainAdminUserName weblogic 
                   -domainAdminPassword /tmp/wlspwd.txt  
   

   где javaHome – директория c JDK;
         archiveLoc – имя файла для экспорта;
         sourceDomainLoc – директория домена;
         sourceMWHomeLoc – директория в которой развернут MW_HOME;
         domainHostName – хост домена;
         domainPortNum – порт AdminServer-а;
         domainAdminUserName – логин администратора;
         domainAdminPassword – путь к текстовому файлу с паролем администратора.
   
5. Скопировать файл экспорта с сервера источника на сервер назначения.
6. На сервере назначения перейти в директорию:
   

    $ cd $MW_HOME/oracle_common/bin/  
   

7. Запускаем генерацию плана переноса домена на сервере назначения:
   

    $ ./extractMovePlan.sh -javaHome /u01/jdk1.6.0_30  
                  -archiveLoc /home/weblogic/clone_domain/soa_domain.jar
                  -planDirLoc /home/weblogic/clone_domain/plan  
   

   где javaHome – директория c JDK;
         archiveLoc – имя файла для экспорта;
         planDirLoc – директория в которую будет сгенерирован план.
   
8. Редактируем сгенерированный план переноса:
   

    $ vi /home/weblogic/clone_domain/plan/moveplan.xml  
   

   Следует обратить внимание на создание текстовых файлов содержащих пароли к Data Source-ам и указание пути к файлу с паролем для каждого конкретного Data Source-а.
   
9. Если требуется, то можно и изменить параметры адаптеров, композитов и деплоймент планов в соответствующих директориях:
   

    $ /home/weblogic/clone_domain/plan/  
    $ ls -l  
    total 312  
    drwxr-xr-x 2 weblogic app  4096 Mar 14 10:47 adapters  
    drwxr-xr-x 2 weblogic app 12288 Mar 14 10:47 composites  
    drwxr-xr-x 2 weblogic app  4096 Mar 14 10:48 deployment_plans  
    -rw-r--r-- 1 weblogic app 274543 Mar 14 10:44 moveplan.xml  
   

10. Запускаем импорт домена на сервере назначения:
    

     $ ./pasteConfig.sh -javaHome /u01/jdk1.6.0_30   
          -archiveLoc /home/weblogic/clone_domain/soa_domain.jar   
          -movePlanLoc /home/weblogic/clone_domain/plan/moveplan.xml  
          -targetDomainLoc /u01/user_projects/domains/clonned_soa_domain  
          -targetMWHomeLoc /u01/ofm/   
          -domainAdminPassword /home/weblogic/clone_domain/plan/domainpwd.txt  
    

    где javaHome – директория c JDK;
          archiveLoc – имя файла для экспорта;
          sourceDomainLoc – директория домена;
          movePlanLoc – имя файла плана переноса;
          targetDomainLoc – директория в которую импортируется домен;
          targetMWHomeLoc – директория в которой развернут MW_HOME;
          domainAdminPassword – путь к текстовому файлу с паролем администратора.
    

---

Основы Oracle Fusion Middleware High Availability

2012-02-20 16:49:00 (читать в оригинале)

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

• Планируемый – запланированные административные операции;
• Непланируемый – любой незапланированный сбой.

Оба типа простоя обычно рассматриваются отдельно когда выставляются требования по высокой доступности. Системам необходимо иметь очень ограниченное время к непланируемым простоям и максимально гибко конфигурированными к планируемым простоям.

Табл.1 Планируемые простои и их решения для семейства продуктов Oracle Fusion Middleware

Операции	Решения
Развертывание и удаление приложений	Hot Deployment
Патчинг	Rolling Patching
Конфигурационные изменения	Online configuration Changes Change Notification Batching of changes Deferred Activation
Масштабируемость	Cluster Scale-Out

Табл.2 Непланируемые простои и их решения для семейства продуктов Oracle Fusion Middleware

Тип сбоя	Решения
Программный сбой	Death Detection and restart using Node Manager for Java EE and OPMN for system components. Server Clusters & Load Balancing Cold Failover Clusters Server Migration Service Migration State Replication and Replica aware Stubs
Аппаратный сбой	Server Clusters & Load Balancing Server Migration Clusterware Integration
Потеря данных	Backup and Recovery
Site Disaster	Oracle Fusion Middleware Disaster Recovery Solution

Решения высокой доступности можно разделить на два вида:

• Локальная высокая доступность – предоставляется в одном датацентре;
• Глобальная высокая доступность – предоставляется в географически различных датацентрах (защищает от региональных бедствий, например наводнений).

Решения локальной высокой доступности можно разделить на два вида:

• «Активный-Активный» - развертываются на двух или более инстансах, которые улучшают масштабируемость и предоставляют высокую доступность . В данном виде все инстансы работают параллельно. Самым ярким примером является кластеризация.
• «Активный-Пассивный» - один инстанс (активный) обслуживает запросы, а другой (пассивный) находится в стадии ожидания. В случае выхода из строя активного инстанса все запросы перенаправляются на выполнение на пассивный инстанс, который становится активным. Пассивный инстанс так же называют standby-инстансом.

Концептуальная схема решения глобальной высокой доступности:

---

Ошибка "java.lang.AssertionError: Could not obtain the localhost address" при старте Weblogic-сервера и вариант её решения

2012-01-26 16:35:00 (читать в оригинале)

Ошибка:
При старте Weblogic-сервера возникает следующая ошибка и происходит ошибка старта (сервер переходит в статус FAILED):

 <BEA-000386> <Server subsystem failed. Reason: java.lang.AssertionError: Could not obtain the localhost address. The most likely cause is an error in the network configuration of this machine.  
 java.lang.AssertionError: Could not obtain the localhost address. The most likely cause is an error in the network configuration of this machine.  
     at weblogic.server.channels.AddressUtils$AddressMaker.getLocalHost(AddressUtils.java:38)  
     at weblogic.server.channels.AddressUtils$AddressMaker.<clinit>(AddressUtils.java:33)  
     at weblogic.server.channels.AddressUtils.getIPAny(AddressUtils.java:154)  
     at weblogic.protocol.configuration.ChannelHelper.checkConsistency(ChannelHelper.java:61)  
     at weblogic.server.channels.ChannelService.start(ChannelService.java:207)  
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)  
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)  
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)  
 Caused By: java.net.UnknownHostException: vm1.mydomain.com : vm1.mydomain.com 
     at java.net.InetAddress.getLocalHost(InetAddress.java:1360)  
     at weblogic.server.channels.AddressUtils$AddressMaker.getLocalHost(AddressUtils.java:36)  
     at weblogic.server.channels.AddressUtils$AddressMaker.<clinit>(AddressUtils.java:33)  
     at weblogic.server.channels.AddressUtils.getIPAny(AddressUtils.java:154)  
     at weblogic.protocol.configuration.ChannelHelper.checkConsistency(ChannelHelper.java:61)  
     at weblogic.server.channels.ChannelService.start(ChannelService.java:207)  
     at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)  
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)  
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)  

Причина:
По имени хоста (выделено синим выше) на котором напускается Weblogic-сервер невозможно получить его IP-адрес.

Решение:
Варианты решения:

• Прописать в DNS
• Прописать в файл /etc/hosts

---

Выгрузка данных по измерениям Hyperion EPMA из Oracle RDBMS

2011-12-19 18:31:00 (читать в оригинале)

---

Методология Oracle Unified Method

2011-11-20 20:27:00 (читать в оригинале)