Encontrar

Artículo
· 12 sep, 2024 Lectura de 3 min

Crear, Listar, Subir y Descargar archivos y carpetas de red usando el protocolo SMB y la interoperabilidad de IRIS

Samba es el estándar para la interoperabilidad de servicios de archivos entre Linux, Unix, DOS, Windows, OS/2 y otros sistemas operativos. Desde 1992, Samba ha proporcionado servicios de archivos seguros, estables y rápidos para todos los clientes (sistemas operativos y programas) utilizando el protocolo SMB/CIFS. Los administradores de red han utilizado SAMBA para crear carpetas de red compartidas que permiten a los empleados de la empresa crear, editar y visualizar archivos corporativos como si estuvieran en sus ordenadores localmente, aunque estos archivos se encuentren físicamente en un servidor de archivos en red. Es posible crear una carpeta de red en Linux y verla como una carpeta compartida en Windows, por ejemplo.

Actualmente, los conectores de IRIS no soportan el acceso ni la escritura de archivos y carpetas remotas usando el protocolo SMB, por lo que es necesario usar FTP. Sin embargo, ahora contamos con Python, que dispone de la librería "smbprotocol" (https://pypi.org/project/smbprotocol). Basado en esta librería, se ha creado una aplicación de interoperabilidad (producción) para listar, grabar y eliminar archivos y carpetas utilizando el protocolo SMB. Ahora, vuestras aplicaciones IRIS pueden escribir o acceder fácilmente a archivos de red. La aplicación se llama "samba-iris-adapter" (https://openexchange.intersystems.com/package/samba-iris-adapter).

 

Instalación de la aplicación

Instalación: ZPM

1. Abrir un Namespace de IRIS con la interoperabilidad habilitada. Abrir la Terminal y ejecutar:

USER>zpm "install samba-iris-adapter"

Instalación: Docker

1. Clonad/haced git pull del repositorio en cualquier directorio local.

$ git clone https://github.com/yurimarx/samba-iris-adapter.git

2. Abrid la terminal en este directorio y ejecutad:

$ docker-compose build

3. Ejecutad el contenedor de IRIS con vuestro proyecto:

$ docker-compose up -d

Cómo iniciar la aplicación

1. Id a Interoperabilidad > Configurar > Credenciales:

2. Estableced las credenciales y guardad con estos valores:

ID: SambaCredentials
User name: bob
Password: bobspasswd 
Credentials

3. Abrid la producción http://localhost:52795/csp/user/EnsPortal.ProductionConfig.zen?PRODUCTION=dc.samba.SambaProduction e iniciarla.

4. Id a vuestra aplicación cliente REST y utilizad estas operaciones REST (con autenticación básica y credenciales _SYSTEM/SYS):

5. Cread una nueva Carpeta Remota: POST http://localhost:52795/csp/samba/CreateFolder con el cuerpo JSON: {"Folder":"samplefolder"}

6. Para enviar un archivo a una Carpeta Remota: POST http://localhost:52795/csp/samba/CreateFile/samplefolder con form-data seleccionado para enviar un archivo multipart. El nombre del archivo multipart es "file" y en el valor seleccionad cualquier archivo de vuestro ordenador. Consultad esta imagen con un ejemplo usando Postman:

7. Listad los archivos dentro de una Carpeta Remota: GET http://localhost:52795/csp/samba/ListFilesIntoFolder/samplefolder:

8. Descargad el archivo: POST http://localhost:52795/csp/samba/DownloadFile con el cuerpo JSON: {"Folder":"samplefolder", "Filename":"cat.jpg"}

9. Ved los mensajes de las producciones en http://localhost:52795/csp/user/EnsPortal.ProductionConfig.zen?$NAMESPACE=USER&$NAMESPACE=USER& > Pestaña Mensajes > haced clic en la Sesión:

10. Comprobad la nueva carpeta y archivo dentro de la carpeta /mnt2 en la instancia Docker de Samba:

¡Disfrutadlo!

Comentarios (0)1
Inicie sesión o regístrese para continuar
Pregunta
· 12 sep, 2024

Running IRIS in a Swarm Cluster

Hi there,

I'm discovering IRIS and I need to POC the solution, with a constraint: containerization.
I'm used to deploy my apps in a Swarm cluster, and all my bind volumes are written on a GlusterFS volume.

The problem here, when I start my stack, the first log is:

[WARN] ISC_DATA_DIRECTORY is located on a mount of type 'fuse.glusterfs' which is not supported, consider a named volume for '/iris_conf'

And of course the deployment fails.

Any idea? How can I provide my data on all my cluster nodes? I read this article: https://community.intersystems.com/post/deploying-sharded-cluster-docker... But no swarm cluster here, it's only docker compose and 3 containers running, which is not I want. I don't want 3 containers, but just one, able to retrieve its data on the same path, without worrying about the cluster node on which it is running. So, any idea of how I can have the same behavior than data replication and availibilty without using GlusterFS?

My infrastructure is a 3 nodes Swarm Cluster, with a GlusterFS volume replicated on the 3 nodes, and keepalived for HA and vIP. And Traefik reverse proxy.

If someone can help me :D it would be nice.

 

Comentarios (0)1
Inicie sesión o regístrese para continuar
Pregunta
· 12 sep, 2024

SYSTEM OBJ Export

I have a DOS batch file that calls *.scr script to back up an existing routine and upload the newly updated one.

I have a backup folder setup in C:\Users\[username]\Backup\ on each server, some with more recent versions of cache. The *.scr script calls on the command:  $SYSTEM.OBJ.Export(routine,path) . 

The problem is that it works consistently in some servers but not in others. Where it fails, the session unexpectedly terminated. Please note that the command works on the remote server terminal window where the script terminates unexpectedly. Is there a setting I need to change in Management Portal or somewhere else for my cache USER and ROLE under my name in the destination server? Is there another system command, perhaps, I should use that is better than OBJ.Export? If so, I have not found it.

Thank you for your anticipated replies.

Comentarios (0)2
Inicie sesión o regístrese para continuar
Artículo
· 12 sep, 2024 Lectura de 2 min

適正なロックテーブルサイズの算出方法

これは InterSystems FAQ サイトの記事です。
 

ロックテーブルの1エントリは管理領域の固定512 bytesとロック文字列情報などの可変領域から構成されます。

 

可変領域はロック対象のグローバルノード名に関連する情報に必要な長さ(bytes)になります。

 

1つのLockコマンドにつき、上記で示した長さのデータが必要です。

 

そしてその可変領域に必要なデータ長は、ロック対象のグローバルノード名(^xxx(xxx,xxx)) の長さに見合う16,32,64,128,256,…bytesのバケットの長さになります。

 

例えばロック対象のグローバルノード名が^xxx(123,"data")とすると、 ^xxx(123,"data")にデータのロケーション等のデータが付加されたものがその可変領域となり、32byteまたは64bytes(データロケーションが相応に長い場合)のバケットを使用しますので、

 

このロックで使用するデータサイズが、64byteのバケットを使用すると仮定すると、

 

512(固定領域)+ 64 (可変領域)= 576 bytes

 

となります。

 

これを基本とし、システムのピーク時に保持することが想定されるロック件数を掛け合わせることで必要なロックテーブルのサイズはある程度は想定することができますが、グローバルノード名に関連する情報が可変であるために正確な見積もりは、一般的には困難です。

 

現実的には、予めおおよその想定使用量より大きめのサイズを仮設定し、運用状況を定期的に観察して、ロックサイズの最大値をモニターしながら調整していくことを推奨します。

 

ロックサイズの最大値をモニターする方法は、カスタマーサポートまでお問い合わせください。

Comentarios (0)1
Inicie sesión o regístrese para continuar
Artículo
· 12 sep, 2024 Lectura de 2 min

gmheapとlocksizの新しいデフォルト値

これは InterSystems FAQ サイトの記事です。
 

IRIS2023.1から導入されたgmheapとlocksizの新しいデフォルト値について紹介します。

 

gmheap=0は、特別な設定の必要性がないほとんどのシステム(実運用システムを含む)に適切なように設計された新しいデフォルト値です。

 

0に設定することで、システムがシステム全体のサイズを推測し、妥当な値を算出してくれます。

 

gmheap=0 に設定した場合、システムは、グローバルバッファ用に設定されたメモリの合計に3%を乗じた値を基準に、300MBの下限と2GBの上限の範囲内でgmheap値を設定します。

 

0以外の値はそれをそのまま使用し、2GBよりはるかに大きく、あるいは300MBよりはるかに小さく設定することができます。

 

(ただし、小さな値を設定した場合、メモリを必要とする機能の利用が失敗する可能性があります。 同様に極端に大きな値を設定することでシステムに悪影響を与える可能性があります)

 

さらにこの変更以前は、.cpfファイルのgmheap設定に加えて、CPUスレッド数 に2MBを掛けた値をシステムが内部的に追加していました。

 

このため、異なるシステムに構成を移動するときや、物理メモリの使用量を理解しようとするときに混乱を招くことがありました。

 

この変更により、この追加は発生しなくなり、gmheap 設定で与えられた値が直接使われるようになりました。

 

以前のバージョンからのアップグレード時には、現在の gmheap 設定は、.cpf ファイルで明示的に設定された値に、明示的にこの量 (2MB * $system.Util.NumberOfCPUs()) を追加することで自動的に調整されます。

 

locksiz=0は、すべてのシステムに適合するように設計された新しいデフォルト値です。

 

この値は、ロックテーブルのサイズがgmheap パラメータで指定された共有メモリヒープのサイズによってのみ制限されることを意味します。

 

システムをバージョンアップする際に現在の locksiz パラメータは自動的に 0 に設定されます。

 

0 以外の値が指定された場合、locksizに指定されたバイト数をgmheap内で使用可能なメモリから確保します。

Comentarios (0)1
Inicie sesión o regístrese para continuar