Terrible laburo, felicitaciones a Alvaro Miranda y Mikael Sandström por la contribución.
Para mi sorpresa en el sitio del RAC Attack tiene documentado parte de esto (el uso de Vagrant) desde hace un par de años. Es algo que en los eventos donde se realiza el RAC Attack no se llega a ver, ya que la idea es ejecutar paso a paso una instalación desde cero aprendiendo del proceso.
Quizás en algún nuevo evento orientado a instalaciones avanzadas se pueda llegar a incluir, junto con el uso de una instalación existente para ver en funcionamiento todos los chiches que lo hacen un producto único (como application continuity por ejemplo).
En este post de Mikael está bien explicado como usar el proyecto completo con Ansible.
Así que para aportar algo además de hacerle propaganda al proyecto, incluyo detalles de como probarlo en Windows 7 64 bits.
Usé una máquina con Intel Core i7-4600 y 16Gb de RAM.
Instalar utilitarios
Ya tenía instalado Git 2.7.0 y VirtualBox 5.1.4, no se necesita actualizarlos a las últimas versiones para que funcione.Tuve que instalar Vagrant en su versión actual 1.9.3.
Cambiar directorio por defecto de Vagrant
Algo importante a ajustar es el directorio donde Vagrant guarda los archivos de las VM, ya que ocupan mucho espacio y nuestro disco C: se puede quedar sin espacio pronto.Por defecto las imágenes de VMs van a C:\Users\USER\.vagrant.d aunque los binarios se hayan instalado en otro disco.
Esto es simple de ajustar: hay que definir la variable de ambiente VAGRANT_HOME y mover el direcotorio C:\Users\USER\.vagrant.d al nuevo. Yo lo moví a otro disco:
set VAGRANT_HOME=D:\vagrant.d move C:\Users\USER\.vagrant.d d:\
Conviene no solo hacerlo en la shell y dejar esta variable de forma permanente en las propiedades del sistema (botón de inicio, "computer" y con el botón derecho elegir propiedades, y "change settings" para abrir el diálogo de propiedades del sistema).
Ahí en el tab "advanced" hay que elegir "Enviroment Variables" y agregar la nueva variable VAGRANT_HOME.
Usando racattack-ansible
Primero hay que clonar el repositorio.Mi directorio de trabajo es d:\github donde solo tengo proyectos:
D:\GitHub>git clone --recursive https://github.com/racattack/racattack-ansible-oracle
Cloning into 'racattack-ansible-oracle'...
remote: Counting objects: 320, done.
Receiving objects: 100% (320/320), 52.22 KiB | 0 bytes/s, done.
remote: Total 320 (delta 0), reused 0 (delta 0), pack-reused 320
Resolving deltas: 100% (210/210), done.
Checking connectivity... done.
Submodule 'stagefiles/ansible-oracle' (https://github.com/oravirt/ansible-oracle) registered for path 'stagefiles/ansible-oracle'
Cloning into 'stagefiles/ansible-oracle'...
remote: Counting objects: 2181, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 2181 (delta 2), reused 0 (delta 0), pack-reused 2169
Receiving objects: 100% (2181/2181), 535.77 KiB | 245.00 KiB/s, done.
Resolving deltas: 100% (1027/1027), done.
Checking connectivity... done.
Submodule path 'stagefiles/ansible-oracle': checked out '00651e0caf9a876fcefe51d21e44a6e78c313e76'
De más está decir que lean el README.md del proyecto donde se explica como usarlo, y los posts mencionados al comienzo para entender mejor lo que sigue.
Copiar archivos de instalación de Oracle 12cR1.
Ya tenía a mano estos archivos y los moví al directorio requerido:
D:\GitHub\racattack-ansible-oracle>dir 12cr1
Volume in drive D is externo
Volume Serial Number is 88CD-FFE4
Directory of D:\GitHub\racattack-ansible-oracle\12cr1
13/04/2017 11:37 AM
.
13/04/2017 11:37 AM..
13/04/2017 11:37 AM 111 .gitattributes
13/04/2017 11:37 AM 0 keep
13/04/2017 11:37 AM 187 readme.txt
29/07/2016 09:35 PM 1,673,519,571 linuxamd64_12102_database_1of2.zip
29/07/2016 09:27 PM 1,014,527,110 linuxamd64_12102_database_2of2.zip
29/07/2016 09:48 PM 1,747,021,273 linuxamd64_12102_grid_1of2.zip
29/07/2016 11:28 PM 646,969,279 linuxamd64_12102_grid_2of2.zip
7 File(s) 5,082,037,531 bytes
2 Dir(s) 688,935,665,664 bytes free
Lo único que tuve que ajustar fueron los nombres de archivos, porque yo tenía estos:
29/07/2016 09:48 PM 1,747,021,273 p21419221_121020_Linux-x86-64_5of10.zip
29/07/2016 11:28 PM 646,969,279 p21419221_121020_Linux-x86-64_6of10.zip
29/07/2016 09:35 PM 1,673,519,571 p21419221_121020_Linux-x86-64_1of10.zip
29/07/2016 09:27 PM 1,014,527,110 p21419221_121020_Linux-x86-64_2of10.zip
Si no los tienen a mano, los pueden bajar del sitio de Oracle
Notar que actualmente están disponibles los binarios de 12.2 y esta configuración usa 12.1.
Al final de la página de descarga en el sitio de Oracle tienen las instrucciones para pedir archivos viejos ya no disponibles.
Creando virtuales
Este es el primer paso, usando 'vagrant up'.
Llevó varios minutos bajar la virtual de OEL6 (1.2Gb) desde https://atlas.hashicorp.com.
Ahora pueden validar que el directorio por defecto de vagrant quedó bien cambiado, ya que estos archivos se guardan en D:\vagrant.d\boxes\kikitux-VAGRANTSLASH-oracle6-racattack\16.01.01\virtualbox
Si lo ejecutaron sin cambiar el archivo de configuración Vagrantfile (en D:\GitHub\racattack-ansible-oracle), van a ver que se creó una sola VM, ya que la configuración por defecto viene para una sola instancia.
Eso es por esta variable:
num_DB_INSTANCES = 1
Y la ejecución con valores por defecto:
D:\GitHub\racattack-ansible-oracle>vagrant up
collabn1 eth1 lanip :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
on first boot shared disks will be created, this will take some time
Bringing machine 'collabn1' up with 'virtualbox' provider...
==> collabn1: Box 'kikitux/oracle6-racattack' could not be found. Attempting to find and install...
collabn1: Box Provider: virtualbox
collabn1: Box Version: >= 0
==> collabn1: Loading metadata for box 'kikitux/oracle6-racattack'
collabn1: URL: https://atlas.hashicorp.com/kikitux/oracle6-racattack
==> collabn1: Adding box 'kikitux/oracle6-racattack' (v16.01.01) for provider: virtualbox
collabn1: Downloading: https://atlas.hashicorp.com/kikitux/boxes/oracle6-racattack/versions/16.01.01/providers/virtualbox.box
collabn1: Progress: 100% (Rate: 590k/s, Estimated time remaining: --:--:--)
==> collabn1: Successfully added box 'kikitux/oracle6-racattack' (v16.01.01) for 'virtualbox'!
==> collabn1: Importing base box 'kikitux/oracle6-racattack'...
==> collabn1: Matching MAC address for NAT networking...
==> collabn1: Checking if box 'kikitux/oracle6-racattack' is up to date...
==> collabn1: Setting the name of the VM: collabn1.1704131427
==> collabn1: Clearing any previously set network interfaces...
==> collabn1: Preparing network interfaces based on configuration...
collabn1: Adapter 1: nat
collabn1: Adapter 2: hostonly
collabn1: Adapter 3: hostonly
==> collabn1: Forwarding ports...
collabn1: 22 (guest) => 2222 (host) (adapter 1)
==> collabn1: Running 'pre-boot' VM customizations...
==> collabn1: Booting VM...
==> collabn1: Waiting for machine to boot. This may take a few minutes...
collabn1: SSH address: 127.0.0.1:2222
collabn1: SSH username: vagrant
collabn1: SSH auth method: private key
collabn1: Warning: Remote connection disconnect. Retrying...
==> collabn1: Machine booted and ready!
==> collabn1: Checking for guest additions in VM...
collabn1: The guest additions on this VM do not match the installed version of
collabn1: VirtualBox! In most cases this is fine, but in rare cases it can
collabn1: prevent things such as shared folders from working properly. If you see
collabn1: shared folder errors, please make sure the guest additions withinthe
collabn1: virtual machine match the version of VirtualBox you have installed on
collabn1: your host and reload your VM.
collabn1:
collabn1: Guest Additions Version: 5.0.0
collabn1: VirtualBox Version: 5.1
==> collabn1: Setting hostname...
==> collabn1: Configuring and enabling network interfaces...
==> collabn1: Mounting shared folders...
collabn1: /vagrant => D:/GitHub/racattack-ansible-oracle
collabn1: /media/sf_12cR1 => D:/GitHub/racattack-ansible-oracle/12cR1
==> collabn1: Detected mount owner ID within mount options. (uid: 54320 guestpath: /media/sf_12cR1)
==> collabn1: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/sf_12cR1)
collabn1: /media/stagefiles => D:/GitHub/racattack-ansible-oracle/stagefiles
==> collabn1: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/stagefiles)
==> collabn1: Running provisioner: shell...
collabn1: Running: inline script
==> collabn1: overwriting /etc/resolv.conf
==> collabn1: Running provisioner: shell...
collabn1: Running: inline script
==> collabn1: wrote key file "/etc/rndc.key"
==> collabn1: Stopping named:
==> collabn1: [ OK ]
==> collabn1: Starting named:
==> collabn1: [ OK ]
==> collabn1: successfully completed named steps
Podemos validar que la VM quedó configurada
D:\GitHub\racattack-ansible-oracle>vagrant box list
kikitux/oracle6-racattack (virtualbox, 16.01.01)
Y podemos entrar usando SSH.
Acá algo que tuve que ajustar: agregar los binarios de Git al path por defecto, ya que estos incluyen una versión de ssh.
D:\GitHub\racattack-ansible-oracle>ssh
'ssh' is not recognized as an internal or external command,
operable program or batch file.
D:\GitHub\racattack-ansible-oracle>vagrant ssh
collabn1 eth1 lanip :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:
Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: D:/vagrant.d/insecure_private_key
D:\GitHub\racattack-ansible-oracle>set PATH=%PATH%;"C:\Program Files\Git\usr\bin"
D:\GitHub\racattack-ansible-oracle>ssh
usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port]
[-Q cipher | cipher-auth | mac | kex | key]
[-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] [user@]hostname [command]
Extrañamente a pesar de tener ssh en el path ahora, no funciona desde vagrant:
D:\GitHub\racattack-ansible-oracle>vagrant ssh
collabn1 eth1 lanip :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:
Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: D:/vagrant.d/insecure_private_key
Pero podemos usarlo directamente y confirmar que la VM está ejecutando:
D:\GitHub\racattack-ansible-oracle>ssh vagrant@127.0.0.1 -p2222 -i D:/vagrant.d/insecure_private_key
The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be establis
hed.
RSA key fingerprint is SHA256:9AOzhyrPyO5Z1/4F9ATt90X0kco87RIdGLSUTw4swgg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:2222' (RSA) to the list of known hosts.
[vagrant@collabn1 ~]$
Para agregar la segunda VM, modificamos el archivo de configuración Vagranfile:
num_DB_INSTANCES = 2
Y volvemos a ejecutar 'vagrant up':
D:\GitHub\racattack-ansible-oracle>vagrant up
collabn2 eth1 lanip :192.168.78.52
collabn2 eth2 privip :172.16.100.52
collabn2 dns server role is slave
collabn1 eth1 lanip :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
Bringing machine 'collabn2' up with 'virtualbox' provider...
Bringing machine 'collabn1' up with 'virtualbox' provider...
==> collabn2: Importing base box 'kikitux/oracle6-racattack'...
==> collabn2: Matching MAC address for NAT networking...
==> collabn2: Checking if box 'kikitux/oracle6-racattack' is up to date...
==> collabn2: Setting the name of the VM: collabn2.1704131511
==> collabn2: Fixed port collision for 22 => 2222. Now on port 2200.
==> collabn2: Clearing any previously set network interfaces...
==> collabn2: Preparing network interfaces based on configuration...
collabn2: Adapter 1: nat
collabn2: Adapter 2: hostonly
collabn2: Adapter 3: hostonly
==> collabn2: Forwarding ports...
collabn2: 22 (guest) => 2200 (host) (adapter 1)
==> collabn2: Running 'pre-boot' VM customizations...
==> collabn2: Booting VM...
==> collabn2: Waiting for machine to boot. This may take a few minutes...
collabn2: SSH address: 127.0.0.1:2200
collabn2: SSH username: vagrant
collabn2: SSH auth method: private key
collabn2: Warning: Remote connection disconnect. Retrying...
==> collabn2: Machine booted and ready!
==> collabn2: Checking for guest additions in VM...
collabn2: The guest additions on this VM do not match the installed version of
collabn2: VirtualBox! In most cases this is fine, but in rare cases it can
collabn2: prevent things such as shared folders from working properly. If you see
collabn2: shared folder errors, please make sure the guest additions within the
collabn2: virtual machine match the version of VirtualBox you have installed on
collabn2: your host and reload your VM.
collabn2:
collabn2: Guest Additions Version: 5.0.0
collabn2: VirtualBox Version: 5.1
==> collabn2: Setting hostname...
==> collabn2: Configuring and enabling network interfaces...
==> collabn2: Mounting shared folders...
collabn2: /vagrant => D:/GitHub/racattack-ansible-oracle
collabn2: /media/sf_12cR1 => D:/GitHub/racattack-ansible-oracle/12cR1
==> collabn2: Detected mount owner ID within mount options. (uid: 54320 guestpath: /media/sf_12cR1)
==> collabn2: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/sf_12cR1)
collabn2: /media/stagefiles => D:/GitHub/racattack-ansible-oracle/stagefiles
==> collabn2: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/stagefiles)
==> collabn2: Running provisioner: shell...
collabn2: Running: inline script
==> collabn2: overwriting /etc/resolv.conf
==> collabn2: Running provisioner: shell...
collabn2: Running: inline script
==> collabn2: Stopping named:
==> collabn2: [ OK ]
==> collabn2: wrote key file "/etc/rndc.key"
==> collabn2: Stopping named:
==> collabn2: [ OK ]
==> collabn2: Starting named:
==> collabn2: [ OK ]
==> collabn2: successfully completed named steps
==> collabn1: Checking if box 'kikitux/oracle6-racattack' is up to date...
==> collabn1: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> collabn1: flag to force provisioning. Provisioners marked to run always will still run.
D:\GitHub\racattack-ansible-oracle>
Una vez que termina, validamos que podemos conectarnos a la nueva VM:
D:\GitHub\racattack-ansible-oracle>ssh vagrant@192.168.78.52 -i D:/vagrant.d/insecure_private_key
The authenticity of host '192.168.78.52 (192.168.78.52)' can't be established.
RSA key fingerprint is SHA256:9AOzhyrPyO5Z1/4F9ATt90X0kco87RIdGLSUTw4swgg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.78.52' (RSA) to the list of known hosts.
Last login: Thu Apr 13 18:20:17 2017 from 192.168.78.51
[vagrant@collabn2 ~]$
Instalar RAC
Con las virtuales corriendo, queda la parte que realmente interesa de ejecutar la instalación automática del RAC: esto incluye todos los pasos de configuración incluídos en el RAC Attack y que dejan las dos instancias funcionando, con ASM y una base de sid racdba.
Mi prueba tomó varias horas, lejos de los 60 minutos que comenta el post original.
Para ejecutarlo usando valores por defecto (BD 12.1, ASM 12.1):
D:\GitHub\racattack-ansible-oracle>set setup=standard
D:\GitHub\racattack-ansible-oracle>vagrant provision
collabn2 eth1 lanip :192.168.78.52
collabn2 eth2 privip :172.16.100.52
collabn2 dns server role is slave
collabn1 eth1 lanip :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
==> collabn2: Running provisioner: shell...
collabn2: Running: inline script
...
El log de esa ejecución es muy largo para incluirlo acá.
Lo bueno es que si algún paso reporta problemas, pueden revisar los logs y luego de resolver el problema de fondo volver a ejecutar 'valgrant provision' que si bien arranca desde el principio, va descartando los pasos que ya fueron completados.
Tuve problemas durante la creación de la base - dbca falla y vagrant aborta.
Como van a ver a continuación, esto es porque el hardware no es suficiente para la configuración usada, o simplemente porque Windows no puede manejar bien la falta de recursos.
Esto no debería ocurrir si tienen mejor hardware y deberían poder completar la instalación sin problemas.
Pero me parece interesante mostrarles como se puede resolver en caso que tengan el mismo problema.
Esto es lo que se ve en la terminal donde estaba corriendo vagrant:
==> collabn1: stderr:
==> collabn1: real 8m13.313s
==> collabn1: user 0m29.813s
==> collabn1: sys 0m5.689s
==> collabn1: stdout: Copying database files
==> collabn1: 1% complete
==> collabn1: 3% complete
==> collabn1: DBCA Operation failed.
==> collabn1: Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/racdba/racdba.log" for further details.
==> collabn1:
==> collabn1: TASK: [oradb-create | debug var=oradbcreate.stdout_lines] ********
...
==> collabn1: PLAY RECAP *******************************************************
********
==> collabn1: *****
==> collabn1: to retry, use: --limit @/root/racattack-full-install.retry
==> collabn1:
==> collabn1: collabn1 : ok=96 changed=32 unreachable=0 failed=1
==> collabn1: collabn2 : ok=102 changed=22 unreachable=0 failed=0
==> collabn1: real 144m15.544s
==> collabn1: user 0m12.850s
==> collabn1: sys 0m14.901s
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
Revisando los archivos de logs, encontré el motivo de la falla:
[oracle@collabn1 ~]$ cat /u01/app/oracle/cfgtoollogs/dbca/racdba/CloneRmanRestore.log
ORA-00445: background process "DBRM" did not start after 120 seconds
BEGIN dbms_backup_restore.resetCfileSection(dbms_backup_restore.RTYP_DFILE_COPY); END;
*
ERROR at line 1:
Process ID: 0
Esto es típico de falta de recursos de hardware.
Ejecutando dbca nuevamente y monitoreando más de cerca, este error se reporta por el proceso VKTM en otras ejecuciones.
Después de algunas pruebas logré resolverlo aumentando el timeout de 120 segundos a 500, agregando este parámetro de inicio a la base:
event='10281 trace name context forever, level 500'
El arreglo simple fue incluirlo en el template que usa DBCA (/u01/app/oracle/12.1.0.2/
Después de esto, la ejecución manual de dbca completó de forma exitosa y la base quedó andando:
[oracle@collabn1 ~]$ /u01/app/oracle/12.1.0.2/rachome1/bin/dbca -responseFile /u01/stage/rsp/dbca_racdba.rsp -silent -redoLogFileSize 100
Copying database files
1% complete
3% complete
9% complete
15% complete
21% complete
27% complete
30% complete
Creating and starting Oracle instance
32% complete
36% complete
40% complete
44% complete
45% complete
48% complete
50% complete
...
[oracle@collabn1 ~]$ ps -eaf | grep pmon
oracle 5971 20007 0 12:36 pts/3 00:00:00 grep pmon
grid 6090 1 0 02:13 ? 00:00:03 mdb_pmon_-MGMTDB
oracle 10222 1 0 10:44 ? 00:00:01 ora_pmon_racdba1
grid 23150 1 0 01:42 ? 00:00:05 asm_pmon_+ASM1
[oracle@collabn1 ~]$[oracle@collabn1 ~]$ export ORACLE_HOME=/u01/app/oracle/12.1.0.2/rachome1
[oracle@collabn1 ~]$ export ORACLE_SID=racdba1
[oracle@collabn1 ~]$ $ORACLE_HOME/bin/sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Fri Apr 14 13:05:53 2017
Copyright (c) 1982, 2014, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options
13:07:31 SYS @ racdba1:>select instance_name, host_name, status from gv$instance;
INSTANCE_NAME
----------------
HOST_NAME STATUS
---------------------------------------------------------------- ------------
racdba1
collabn1.racattack OPEN
Luego de esto volví a ejecutar 'valgrant provision' pero reporta error nuevamente con la ejecución de dbca, aunque el log no muestra errores esta vez y la instancia creada antes sigue en ejecución.
Claramente necesita más investigación para poder retomar desde esta situación.
La solución simple para evitar esto sería limpiar la instalación y empezar nuevamente (setup=clean) agregando en algún paso el ajuste al template que es necesario para el harware que estoy usando.
Esos detalles quedan para un próximo post.
Un saludo
No hay comentarios.:
Publicar un comentario