INFORMIXDIR and files configuration / INFORMIXDIR e configuração de ficheiros

Setting up INFORMIXDIR and instance files, specially in a cluster configuration (original version here: http://informix-technology.blogspot.com/2016/11/informixdir-and-files-configuration.html)


English version
Ok... the article title is a bit confusing, but sometimes so is this subject. I've received a few questions about how to setup the Informix related files, in particular if a cluster (active/passive) configuration is being used. Let's start by listing the files I'm referring to

Files or directories we can configure

• INFORMIXDIR
  The product installation directory. Note that different instances can share a single $INFORMIXDIR
• ONCONFIG file
  This is the instance configuration file. All the parameters for instance initialization and subsequent startups are contained in this file. This file is pointed to by the environment variable $ONCONFIG, but the variable only specifies the file name. The file location must be $INFORMIXDIR/etc
• online.log
  This is the instance log file where the instances messages will be written. The file can have the name we want and it's location is defined by an $ONCONFIG parameter (MSGPATH)
• SQLHOSTS
  This is the file containing the names, addresses, ports, protocols and options of each listener. By default it's $INFORMIXDIR/etc/sqlhosts, but it can be overridden by the value in $INFORMIXSQLHOSTS variable (full PATH)
• chunks
  The chunks are Informix datafiles. In the good old days, when everybody was using RAW devices, the recommendation used to be creating symbolic links that would point to the raw devices. I still like to do this, even when using cooked files (datafiles in operating system file system). It gives us an extra flexibility in case we need to move the physical files
• console file
  This file is somehow "ignored" by many customers. It's a file where some messages are written. We don't normally need to check it. The full path is defined by an $ONCONFIG parameter (CONSOLE)
• Restore point dir
  This is a file system location (directory) where Informix write some information during upgrades. It's defined by an $ONCONFIG parameter (RESTORE_POINT_DIR)
• LTAPEDEV/TAPEDEV
  These are the locations for logical log backup and instance backups, defined by the $ONCONFIG parameters with the same names. They can be defined with a special value ("/dev/null") if you want/need to discard the objects. Note that LTAPEDEV requires an instance restart if we're changing it to/from "/dev/null". Normally they'll point to a directory in the file system (or a file on very old Informix versions). If we're using a storage manager, their value is not really important (unless we're referring to LTAPEDEV and it has the "/dev/null" value - this is not compatible with the use of onbar and a storage manager)
• BAR activity log
  The onbar activity log. Defined by the $ONCONFIG parameter BAR_ACT_LOG
• BAR debug log
  The onbar debug log. Only used for debugging and pointed to by the $ONCONFIG parameter BAR_DEBUG_LOG
• IXBAR file
  The very important file which contains the onbar catalog. This is defined by an $ONCONFIG parameter (BAR_IXBAR_PATH). The default is $INFORMIXDIR/etc/ixbar.N where "N" is the instance SERVERNUM
• BAR BSA library path
  The full location of the XBSA library we're using, if we setup a storage manager. The location will be dependent on the storage manager Informix client installation. The value is defined in the BAR_BSA_LIBPATH $ONCONFIG parameter
• Database Library Path
  The location where we allow the engine to load dynamic libraries for extensibility purposes. The location is defined by the $ONCONFIG parameter DB_LIBRARY_PATH
• Data Replication lost and found
  Base file name for HDR environments to store transactions committed on a primary server that were not successfully transmitted to the secondary server. This is defined by the $ONCONFIG parameter DRLOSTFOUND
• Dump directory
  The directory where shared memory dumps and diagnostic files will be written. This must be a filesystem location with enough storage for a few shared memory dumps (assuming the instance is configured to create them in case of failure). The location is defined by an $ONCONFIG parameter (DUMPDIR)
• Alarmprogram
  The script/program to run when certain events happen. The location is defined by an $ONCONFIG parameter (ALARMPROGRAM)
• System alarm program
  The system alarm program/script. This one is called when serious (crash/assert fails) happen and is defined by an $ONCONFIG parameter (SYSALARMPROGRAM)
• Java Virtual Processor log
  File that takes trace outputs and stack dumps from the java virtual CPUs. Defined in the $ONCONFIG parameter JVPLOGFILE
• ADTCFG file
  This is the file controlling the auditing feature. It exists in $INFORMIXDIR/aaodir. After chnages are made the system creates an adtcfg.N where N is the value of SERVERNUM.

Aspects to consider

The INFORMIXDIR

The first thing to consider is the $INFORMIXDIR. Many people usually use /opt/informix, or /usr/informix and install the product there. This is not the best option because when we're planning an upgrade we need to have both the old and the new version available. Some customers solve this by installing the product in a directory that contains the version (let's assume "my" standard) like /usr/informix/srvr1210fc7w1 and then create a symbolic link /usr/informix/server and point it to the version they want to use. This may work for a single instance, but becomes problematic if you use several instances and you want the option to upgrade them at different moments

The existence of a cluster configuration raises another problem. Should you install the product on both nodes, or just in a single cluster controlled path that moves between nodes? There are people who defend the idea of a single INFORMIXDIR installation which is moved to the active node. But again, if you have several instances and you consider spreading them across the two nodes (all in a single node if the hardware fails or needs maintenance) that won't fulfill the requirements. A single $INFORMIXDIR moving between nodes simplifies other issues. If you have an INFORMIXDIR on node A, and an INFORMIXDIR on node B, you'll have two $ONCONFIG, ADTCFGs and maybe a few others that you cannot define their full path.

Another aspect related to this, is that if you configure role separation (a very nice and free Informix feature that allows different people to have different security functions in an Informix instance), if you have a single INFORMIXDIR for several instances, you can't separate the roles differently across the instances. In most cases this would not be an issue. Actually most customers don't have enough people managing the database to be able to separate the roles even for a single instance.

The log files

The log files, like online.log, onbar activity and debug logs etc. sometimes have defaults that are inside $INFORMIXDIR, and even when the defaults are not like that, too often I find customers that put them there. The problem in doing that is simple. When we upgrade, the logs history becomes "broken" because now you have logs inside the old and the new $INFORMIXDIR.

Another obvious problem with logs comes from cluster environments where an instance moves from node A to node B. If the logs are not pointing to a common cluster resource you'll have parts of the logs spread across the nodes.
On the other hand, if the logs are pointing to a common location we loose track of where the instance was started. And for problem analysis this is important (more about this in a later article).

The chunks

The decision here is if we use symbolic links or not. This used to be much more important because sometimes a change in the raw devices would mean a different path. And we couldn't change the path of the chunks as the engine knows them. In modern systems and Informix versions, we can create the raw devices with specific names (so if we need to rebuild or change some options we can re-use the old names) and we can change the path name of the chunks by doing a "fake" external backup/restore with chunk renaming.

The scripts

Usually the instances require a set of scripts maintained by the DBAs. Once again, too many often I see these scripts inside the $INFORMIXDIR, or $INFORMIXDIR/bin. As mentioned earlier, this is not a good practice because during upgrades it would be a mess, and the same happens if you run several instances on the same box and consider having different INFORMIXDIRs (one reason would be that they can be in different versions).

The tricky part is that sometimes the scripts must be customized for each instance. And another problem (again) arises from the use of a cluster environment. In that case you may need to keep as many copies of the scripts as nodes you're running. Eventually, if the cluster allows you to have a common mount point or a cluster filesystem (like GPFS, or GFS/GFS2) you may have a solution. For situations where a single script must have different configurations for different instances, we can use a "case/esac" structure in SHELL conditioned by $INFORMIXSERVER. This is a possibility for example to implement a common alarm program which may need to have different backup configurations for example.

Recommendations

INFORMIXDIR

I usually install the product in locations that clearly indicate the version (/usr/informix/srvr1210fc7w1). But then I use a script (ixvirtdir) to create a "special" INFORMIXDIR for each specific instance. The script takes a few parameters like the existing INFORMIXDIR and the new one which I normally define with a suffix equal to the instance name. Additionally we can provide operating system groups that will be used as DBSA, AAO and DBSSO for role separation. The "special" INFORMIXDIR will be a new directory where inside I'll create a link to each original INFORMIXDIR's sub-directory with a few exceptions. Let's see an example:

castelo@primary:informix-> echo $INFORMIXSERVER $INFORMIXDIR
castelo /opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> pwd
/opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> ls -l
total 84
drwxrwx--- 2 informix ixaao    4096 Aug 18 02:46 aaodir
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 bin -> /opt/informix/srvr1210fc7w1/bin
drwxrwx--- 2 informix ixdbsso  4096 Aug  1 13:44 dbssodir
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 demo -> /opt/informix/srvr1210fc7w1/demo
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 doc -> /opt/informix/srvr1210fc7w1/doc
drwxrwxr-x 4 informix ixdbsa   4096 Aug 23 11:10 etc
lrwxrwxrwx 1 informix informix   34 Nov 13 03:21 extend -> /opt/informix/srvr1210fc7w1/extend
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 gls -> /opt/informix/srvr1210fc7w1/gls
lrwxrwxrwx 1 informix informix   33 Nov 13 03:21 gskit -> /opt/informix/srvr1210fc7w1/gskit
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 help -> /opt/informix/srvr1210fc7w1/help
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 incl -> /opt/informix/srvr1210fc7w1/incl
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 isa -> /opt/informix/srvr1210fc7w1/isa
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 lib -> /opt/informix/srvr1210fc7w1/lib
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 license -> /opt/informix/srvr1210fc7w1/license
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 msg -> /opt/informix/srvr1210fc7w1/msg
lrwxrwxrwx 1 informix informix   38 Nov 13 03:21 properties -> /opt/informix/srvr1210fc7w1/properties
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 release -> /opt/informix/srvr1210fc7w1/release
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 SDK -> /opt/informix/srvr1210fc7w1/SDK
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 snmp -> /opt/informix/srvr1210fc7w1/snmp
drwxrwx--- 3 informix ixdbsa   4096 Aug  1 13:44 ssl
drwxrwx--- 2 informix informix 4096 Aug 23 11:10 tmp

So, INFORMIXDIR is /opt/informix/srvr1210fc7w1_castelo. "castelo" is the INFORMIXSERVER which acts as a suffix. Most sub-directories are just links to the base product installation. The exceptions are "aaodir", "dbssodir", "etc", "ssl" and "tmp". These are real directories for several reasons. In a cluster configuration, the "virtual" INFORMIXDIR would be on a cluster resource and the base product installation would either also be in a cluster resource (single instance on the machine, or if the decision to move to another node would imply move all the instances), or a local product installation. Note that by creating that list of sub-directories as real directories, I'm isolating everything that can vary from one instance to the other. Note also that these sub-directories would not contain very large content, with the possible exception for "tmp" if it's defined as the DUMPDIR for example.
With this method we can achieve maximum flexibility and instance isolation in the following situations:

1. Several instances on a single machine
2. Cluster environments even with several instances that don't necessarily move from one node to another as a group
3. Full role separation at each instance level, allowing for different groups for different instances

Informix user home

The home of the informix user (let's assume /home/informix) will contain two directories: "bin" and "etc". In the "bin" directory I put every script I use for the instances management including the alarmprogram.sh. In the "etc" I put all the configuration scripts/files like:

• sqlhosts (single file per machine) facilitates configurations for distributed queries etc.
• The configuration file (infx_env.lst) for my script to position across the instances environment (setinfx)
• The configuration file for the alarmprogram.sh (alarm_conf.sh) where each instance specific configurations are defined in a case/esac structure

This setup does not solve the cluster problems. In a cluster environment, assuming all the nodes may have some instance(s) running at the same time, this structure must be replicated across nodes. If however you move all the instances as a single block, the /home/informix could be a cluster resource (or at least the two sub-directories - /home/informix/etc and /home/informix/bin ). In any case the "bin" directory must be placed in the PATH environment variable.
We should also try to avoid having two copies of configuration files like $INFORMIXSQLHOSTS, and we may consider using symbolic links to a shared location.

Log files and others

Things like online.log, onbar activity and debug files, ixbar etc should be put on a cluster resource that moves with each instance. On a non cluster environment these files can be created inside a informix's HOME sub-directory like /home/informix/logs and /home/informix/conf.
Even if the files are created inside a cluster resource, specific for each instance I prefer to create the files with a suffix like INFORMIXSERVER (e.g. online_${INFORMIXSERVER}.log, ixbar.${INFORMIXSERVER} etc.
It's important to underline the importance of having a single IXBAR file in the cluster. Otherwise you'll have the catalog information spread across the cluster and it will make the restore process impossible.

Chunks and links

For the chunks I still prefer to use symbolic links. These can point to cooked files or RAW devices. Both the links and the files (RAW or cooked) must be configured as a cluster resource on a cluster environment.

DUMP dirs

There are a few directories that are used sporadically but are very important. One is the configuration of the parameter DUMPDIR where the assert fail files are written. Somehow similar are the parameters RESTORE_POINT_DIR, DRLOSTFOUND and PLOG_OVERFLOW_PATH.
These are important for certain activities, but typically once the issue is solved the files can and are removed. So, it's important that their locations point to large enough and existing directories, but it's not very relevant if they're specific for each instance or a single cluster location.


Versão Portuguesa
OK... o título do artigo é um pouco confuso, mas por vezes também este assunto o é. Tenho recebido algumas questões sobre como configurar os ficheiros usados pelo Informix, em particular num ambiente de cluster (ativo/passivo). Comecemos por enunciar uma lista de ficheiros a que me estou a referir.

Ficheiros ou diretórios que podemos configurar

• INFORMIXDIR
  O diretório de instalação do produto. Note-se que diferentes instâncias podem partilhar um único $INFORMIXDIR
• Ficheiro ONCONFIG
  É o ficheiro de configuração da instância. Todos os parâmetros para a inicialização da instância e sub-sequentes arranques estão contidos neste ficheiro. A variável de ambiente $ONCONFIG aponta para o nome do ficheiro, sendo que a sua localização é forçosamente $INFORMIXDIR/etc
• online.log
  O ficheiro de log onde as mensagens da instância são escritas. O ficheiro pode ter o nome e localização que quisermos e isto é definido pelo parâmetro MSGPATH no $ONCONFIG
• SQLHOSTS
  O ficheiro que contém os nomes, endereços, portos TCP, protocolos e opções de cada listener. Por omissão a sua localização é $INFORMIXDIR/etc/sqlhosts, mas pode ser redefinido pelo valor da variável de ambiente $INFORMIXSQLHSOSTS (caminho completo)
• chunks
  Os chunks são os "ficheiros" de dados do Informix. Nos bons velhos tempos em que toda a gente usava dispositivos RAW, a recomendação era utilizar links simbólicos que apontariam para esses dispositivos. Eu ainda gosto desta ideia, mesmo que se utilizem ficheiros em filesystem (cooked files). Esta opção oferece uma flexibilidade extra caso necessitemos de mover os ficheiros físicos
• Ficheiro "console"
  Este ficheiro costuma ser de alguma forma ignorado por muitos clientes. É um ficheiro onde algumas mensagens são escritas. Normalmente não é muito necessário verificar estas mensagens. O caminho completo é definido por um parâmetro do $ONCONFIG (CONSOLE)
• Restore point dir
  É uma localização em filesystem (diretório) onde o Informix escreve alguma informação durante os upgrades. É definido por um parâmetro do $ONCONFIG (RESTORE_POINT_DIR)
• LTAPEDEV/TAPEDEV
  São as localizações para o backup dos logical logs e backup de instâncias, definidos pelos parâmetros de $ONCONFIG com o mesmo nome. Podem ser definidos com um valor especial ("/dev/null") se quisermos descartar os objetos. Note-se que o LTAPEDEV requer um restart da instância para mudar de/para "/dev/null". Normalmente apontam para um diretório no file system (ou em versões muito antigas do Informix apontarão para ficheiros). Se usarmos um storage manager o seu valor não é muito importante (exceto se o LTAEPDEV estiver para "/dev/null" - isto não é compatível com a utilização de um storage manager), visto que na realidade os objetos não serão guardados nesta localização, mas antes enviados para o storage manager.
• Log de atividade do onbar
  Log de atividade de backup usando o onbar. Definido por um parâmetro do $ONCONFIG (BAR_ACT_LOG)
• Log de debug do onbar
  Localização onde é escrito o debug do onbar. Apenas é usado se ativarmos o debug. O seu valor é definido por um parâmetro do $ONCONFIG (BAR_DEBUG_LOG)
• Ficheiro IXBAR
  Um ficheiro muito importante que contém o catálogo do onbar. É definido pelo parâmetro BAR_IXBAR_PATH do $ONCONFIG. Por omissão é $INFORMIXDIR/etc/ixbar.N onde "N" é o valor do parâmetro SERVERNUM (único para cada instância)
• Caminho da biblioteca BAR BSA
  O caminho completo para a biblioteca XBSA que estamos a usar, caso estejamos a integrar com um storage manager. A localização será dependente da instalação do cliente Informix do storage manager. O valor é definido pelo parâmetro BAR_BSA_LIBPATH do $ONCONFIG
• Database Library Path
  A localização onde permitimos que o motor carregue bibliotecas dinâmicas para fins de extensibilidade. O valor é definido pelo parâmetro DB_LIBRARY_PATH do $ONCONFIG
• Data Replication lost and found
  Nome base onde os ambientes HDR podem guardar transações committed no servidor primário que não foram transmitidas com sucesso para o servidor secundário. Definido pelo parâmetro DRLOSTFOUND do $ONCONFIG
• Diretório de dumps
  Directório onde os dumps de memória partilhada e ficheiros de diagnóstico serão criados. Tem de ser uma localização com espaço suficiente para alguns dumps de memória (assumindo que a instância está configurada para os gerar em caso de falhas). A localização é definida pelo parâmetro "DUMPDIR" do $ONCONFIG
• Alarmprogram
  O script ou programa que é executado pelo motor quando certos eventos acontecem. A localização é definida pelo parâmetro ALARMPROGRAM do $ONCONFIG
• System alarm program
  Semelhante ao alarmprogram mas para ser chamado em casos de falhas graves (quedas do motor ou assert fails). Definido pelo parâmetro SYSALARMPROGRAM do $ONCONFIG
• Log dos processadores virtuais para Java
  Ficheiro que recebe os "traces" e "dumps" de "stack" do JVPs. Definido pelo parâmetro JVPLOGFILE do $ONCONFIG
• ADTCFG
  Ficheiro de configuração do audit. Existe no diretório $INFORMIXDIR/aaodir e depois de efetuadas alterações será criado o ficheiro adtcfg.N onde N é o valor do parâmetro $SERVERNUM

Aspetos a considerar

  O INFORMIXDIX

A primeira coisa a considerar é o valor de $INFORMIXDIR. Muitas pessoas simplesmente usam /opt/informix ou /usr/informix e instalam aí o produto. Isto não é a melhor opção pois durante os upgrades devemos ter disponíveis ambas as versões (antiga e nova). Em alguns casos resolvem isto instalado o produto num diretório que contém a versão (vamos assumir o "meu" standard) como /usr/informix/srvr1210fc7w1 e depois criam um link simbólico do tipo /usr/informix/server que aponta para a instalação que pretendem usar. Isto pode funcionar quando existe apenas uma instância no servidor, mas torna-se complicado quando há várias instalações e se pretende a opção de fazer upgrades em alturas diferentes.

A existência de um cluster levanta ainda mais um problema. Deveremos instalar o produto em ambos os nós ou apenas numa localização controlada pelo cluster e que é movida entre os nós? Há quem defenda a ideia de uma única instalação (INFORMIXDIR) que é movida para o nó que se quer "ativo". Mas novamente, se temos várias instâncias e consideramos dividir a carga entre os nós (apenas tendo as instâncias todas num só nó se o outro estiver indisponível), uma só instalação não responde aos requisitos. Ter um só $INFORMIXDIR para cada instância que é movido dentro do cluster simplifica outros aspetos. Se temos um INFORMIXDIR no nó A, e outro INFORMIXDIR no nó B, teremos dois ficheiros $ONCONFIG, ADTCFG e eventualmente outros cujo caminho não pode ser mudado (só o nome).

Outro aspeto relacionado com isto, é se configurarmos a separação de funções (role separation), que é uma excelente funcionalidade do Informix (sem custos adicionais) que permite que diferentes grupos de pessoas tenham acesso a diferentes funções numa instância Informix, então um só INFORMIXDIR para várias instâncias não permite fazer também a segregação por instância. Embora na realidade a maioria dos clientes não tenha pessoas suficientes para a separação de uma única instância...

Ficheiros de log

Os ficheiros de log, como o online.log, o de actividade do onbar, o de debug do onbar etc. por vezes têm valores por omissão dentro do $INFORMIXDIR, e mesmo quando assim não é, muitas vezes encontro clientes que os colocam lá. O problema de fazer isto é simples. Quando fazemos um ugrade o histórico dos ficheiros perde-se, pois parte fica no $INFORMIXDIR antigo e outra parte no novo (ou obriga a cópia para que tal não aconteça)

Outro problema óbvio com os logs deriva de ambientes de cluster onde as instâncias "saltitam" entre o nó A e o nó B. Se os logs não estiverem a apontar uma uma localização comum nos dois nós, acabamos com partes dos ficheiros no nó A e outra parte no nó B.

Por outro lado, se os logs estiverem a apontar para uma localização comum perdemos o registo de onde estava a instância em cada momento (o que pode ser conveniente para despiste de problemas - mais sobre isto num futuro artigo)

Os chunks

Aqui a decisão é se usamos links simbólicos ou não. Isto era muito mais importante antigamente porque por vezes alguma alteração nos raw devices implicava um caminho diferente e não era possível trocar o nome dos chunks pelo qual o motor os conhece. Em ambientes modernos e versões recentes do Informix, podemos criar os raw devices com os nomes que quisermos (se necessitarmos de reconstruir ou mudar opções podemos re-utilizar os nomes), e também podemos mudar os caminhos como o Informix os conhece através de um falso backup/restore externo.

Os scripts

Normalmente as instâncias requerem um conjunto de scripts mantidos pelos DBAs. Mais uma vez, vezes demais eu vejo estes scripts dentro do $INFORMIXDIR ou $INFORMIXDIR/bin. Como mencionado atrás isto não é uma boa prática, pois durante os upgrades torna-se uma confusão, e o mesmo se passa se necessitarmos de várias instâncias no mesmo servidor e pensarmos em ter vários $INFORMIXDIR (bastando para isso que estejam em versões diferentes)

O difícil pode ser que alguns scripts podem ter se ser adaptados para cada instância. E novamente a existência de um cluster pode trazer problemas. Neste caso poderemos ter de manter tantas cópias quantos nós existam no mesmo. Se porventura o cluster permitir algum tipo de sistema de ficheiros partilhado (GPFS ou GFS/GFS2 por exemplo), poderá haver solução para isso.
Os casos em que um só script tem de estar adaptado a várias instâncias poderemos usar uma estrutura "case/esac" dentro do script, cujo condicionamento terá por base o valor de $INFORMIXSERVER. Podemos usar isto por exemplo para ter um "alarmprogram" comum, que pode ter por exemplo diferentes tipos de configuração de backups.

Recomendações

INFORMIXDIR

Normalmente instalo o produto numa localização que indique claramente a versão (/usr/informix/srvr1210fc7w1), mas depois utilizo um script (ixvirtdir) para criar um $INFORMIXDIR "especial" para cada instância. O script recebe alguns parâmetros como o $INFORMIXDIR existente (da instalação) e o novo (que normalmente defino com um sufixo igual ao INFORMIXSERVER). Opcionalmente posso dar os grupos de sistema operativo a que correspondem os DBSA, AAO e DBSSOs para a separação de funções.
O INFORMIXDIR "especial" será um novo diretório onde serão criados links simbólicos para os sub-diretórios existentes dentro de $INFORMIXDIR, com algumas exceções. Vejamos um exemplo:

castelo@primary:informix-> echo $INFORMIXSERVER $INFORMIXDIR
castelo /opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> pwd
/opt/informix/srvr1210fc7w1_castelo
castelo@primary:informix-> ls -l
total 84
drwxrwx--- 2 informix ixaao    4096 Aug 18 02:46 aaodir
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 bin -> /opt/informix/srvr1210fc7w1/bin
drwxrwx--- 2 informix ixdbsso  4096 Aug  1 13:44 dbssodir
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 demo -> /opt/informix/srvr1210fc7w1/demo
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 doc -> /opt/informix/srvr1210fc7w1/doc
drwxrwxr-x 4 informix ixdbsa   4096 Aug 23 11:10 etc
lrwxrwxrwx 1 informix informix   34 Nov 13 03:21 extend -> /opt/informix/srvr1210fc7w1/extend
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 gls -> /opt/informix/srvr1210fc7w1/gls
lrwxrwxrwx 1 informix informix   33 Nov 13 03:21 gskit -> /opt/informix/srvr1210fc7w1/gskit
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 help -> /opt/informix/srvr1210fc7w1/help
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 incl -> /opt/informix/srvr1210fc7w1/incl
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 isa -> /opt/informix/srvr1210fc7w1/isa
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 lib -> /opt/informix/srvr1210fc7w1/lib
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 license -> /opt/informix/srvr1210fc7w1/license
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 msg -> /opt/informix/srvr1210fc7w1/msg
lrwxrwxrwx 1 informix informix   38 Nov 13 03:21 properties -> /opt/informix/srvr1210fc7w1/properties
lrwxrwxrwx 1 informix informix   35 Nov 13 03:21 release -> /opt/informix/srvr1210fc7w1/release
lrwxrwxrwx 1 informix informix   31 Nov 13 03:21 SDK -> /opt/informix/srvr1210fc7w1/SDK
lrwxrwxrwx 1 informix informix   32 Nov 13 03:21 snmp -> /opt/informix/srvr1210fc7w1/snmp
drwxrwx--- 3 informix ixdbsa   4096 Aug  1 13:44 ssl
drwxrwx--- 2 informix informix 4096 Aug 23 11:10 tmp

Portanto, o INFORMIXDIR é /opt/informix/srvr1210fc7w1_castelo. "castelo" é o INFORMIXSERVER que atúa como sufixo para se identificar facilmente a que instância pertence. A maioria dos sub-diretórios dentro do $INFORMIXDIR são apenas links simbólicos para a instalação base do produto. As exceções são "aaodir", "dbssodir", "etc", "ssl" e "tmp". Estes são criados como sub-diretórios por várias razões. Num ambiente cluster o INFORMIXDIR "virtual" pode ser um recurso de cluster e a instalação base seria ou um recurso de cluster (no caso se haver apenas uma instância, ou se a movimentação for feita em bloco), ou uma instalação local em cada nó. Note-se que ao criar aquela lista específica de sub-diretórios como sub-diretórios reais, estou a isolar tudo o que pode variar de uma instância para outra. Note-se também que tipicamente estes diretórios não deverão requerer muito espaço, com a possível exceção do "tmp" se estiver definido como DUMPDIR por exemplo.
Com este método podemos alcançar o máximo de flexibilidade e isolamento das instâncias para as seguintes situações:

1. Várias instâncias num só servidor
2. Ambiente de cluster, mesmo com várias instâncias que não sejam necessariamente movidas em bloco para outro(s) nós
3. Completa separação de papéis em cada instância, permitindo diferentes grupos para diferentes instâncias

$HOME do utilizador Informix

A $HOME do utilizador informix (vamos assumir /home/informix) deverá conter duas diretorias:
"bin" e "etc".  Na "bin", coloco todos os scripts que utilizo para gestão das instâncias, incluindo o alarmprogram.sh. Na "etc" coloco todos os ficheiros ou scripts de configuração como:

• sqlhosts (ficheiro único por máquina) facilita as configurações para queries distribuídas etc.
• Ficheiro de configuração do meu script que permite posicionar o ambiente de cada instância (setinfx)
• Ficheiro de configuração do alarmprogram.sh onde cada secção específica para cada instância é permitido por uma estrutura case/esac

Esta configuração não resolve os problemas de cluster. Num ambiente de cluster, assmindo que todos os nós podem ter alguma(s) instãncia(s) a correr ao mesmo tempo a estrutura da $HOME do informix tem de ser replicada pelos nós. No entanto se mover as instâncias em bloco, o diretório pode ser um recurso de cluster (ou pelo menos as duas referidas sub-diretorias). Em qualquer caso o "bin" tem de ser colocado na variável de ambiente $PATH.
Deve ser evitada a duplicação dos ficheiros de configuração (um por cada nó do cluster), nomeadamente do $INFORMIXSQLHOSTS, para que baste alterar num só nó. Uma hipótese para isto seria criar links simbólicos para um ficheiro num recurso de cluster

Log files and others

Coisas como o online.log, ficheiros de atividade e debug do onbar, ixbar.* etc. devem ser colocados num recurso de cluster que seja movido com a instância. Num ambiente não cluster estes ficheiros podem ser colocados por exemplo num sub-diretório da $HOME do informix como /home/informix/logs e /home/informix/conf
Mesmo que os ficheiros sejam criados num recurso de cluster associado à instâncias, prefiro criá-los com um sufixo como $INFORMIXSERVER (ex: online_$INFORMIXSERVER.log, ixbar.$INFORMIXSERVER etc.
É importante sublinhar a importância de ter apenas um IXBAR no cluster. Caso contrário iremos acabar com o catálogo espalhado pelo cluster o que tornará o processo de restore muito difícil ou impossível.

Chunks e links

Para os chunks ainda continuo a preferir usar links simbólicos. Estes podem apontar para cooked files ou RAW. Tantos os links como os ficheiros (RAW ou cooked) devem ser configurados como um recurso de cluster.

Diretórios de DUMP

Existem alguns diretórios que só são usados esporadicamente mas que são muito importantes. Um é usado na configuração do parâmetro DUMPDIR, onde os ficheiros de assert fails são escritos. De alguma forma semelhantes são os parâmetros RESTORE_POINT_DIR, DRLOSTFOUND e PLOG_OVERFLOW_PATH.
Estes são importantes em certas ocasiões ou actividades, mas normalmente após resolvido o problema os ficheiros podem ser removidos. Portanto, é importante que as suas localizações tenham espaço suficiente e sejam diretórios existentes, mas não é assim tão relevante se são específicos de uma instância ou uma só localização em cluster.