Azure Parameter Description
Parameter Name | DataType | Optional | Default | Description | Example/Values | Available since Version |
|---|---|---|---|---|---|---|
type | String | no | Definition of Content Service type. | azureblobstorev2 | ||
connectionstring | String | no | Azure Connection String. | DefaultEndpointsProtocol=https;AccountName=<azurename>;AccountKey=<tiacore/UA==>;EndpointSuffix=core.windows.net | 2.0.8 | |
container | String | no | Azure Container Name. | 2.0.8 | ||
contrepinpath | Boolean | yes | true | Root folder starts with Repository Syntax. | true/false | 2.0.8 |
cleanversions | Boolean | yes | true | true = deletes all previous versions for "UPDATE" and "DELETE" operations in buckets with versioning. false = all versions still persist. | true/false | 1.9.0 |
calculatestreamhash | Boolean | yes | true | After successful encryption, the hash values are recalculated. | true/false | 2.0.8 |
invalidcharacters | String | yes | This parameter can be used to define additional characters that require the name to be encoded for Azure. | <user>, z.B. \uFFFE\uFFF9\uFFF0 | 2.0.8 | |
region | String | yes | azure | Selection of the region for the creation of a new container. | azure, germany, us, china | 2.0.8 |
minparallelsize | Num | yes | 4194304 | Limit for upload in bytes for parallel upload with multiple threads. | 2.0.8 | |
maxconcurrency | Num | yes | 2 | Maximum amount of threads for parallel uploads. | 2.0.8 | |
blocksize | Num | yes | 4194304 | Blocksize in Bytes for parallel upload. | 2.0.8 | |
singleuploadsize | Num | yes | 4194304 | Chunk size for parallel upload in bytes. | 2.0.8 |
Configuration example
<Repo>.contentservice.azureblobstorev2.type = <Repo>.contentservice.azureblobstorev2.connectionstring = <Repo>.contentservice.azureblobstorev2.container = <Repo>.contentservice.azureblobstorev2.contrepinpath = true <Repo>.contentservice.azureblobstorev2.cleanversions = true <Repo>.contentservice.azureblobstorev2.calculatestreamhash = true <Repo>.contentservice.azureblobstorev2.invalidcharacters= <Repo>.contentservice.azureblobstorev2.region = azure <Repo>.contentservice.azureblobstorev2.minparallelsize = 4194304 <Repo>.contentservice.azureblobstorev2.maxconcurrency = 2 <Repo>.contentservice.azureblobstorev2.blocksize = 4194304 <Repo>.contentservice.azureblobstorev2.singleuploadsize = 4194304
Azure Versioning Blob Container
The Azure configuration described below (versioned blob container) supports object individual retention as well as legal hold functionality.
To use this feature, it is necessary to create a container with the "version-level immutability" option. See: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope?tabs=azure-portal
This can be enabled in the Azure StorageAccount in a manually creation process of a container or via a corresponding configuration in tia Core, which is described below.
If the container creation is to be done by tia core, the following parameters must be added to the repository.cfg.
Parameter Name | DataType | Optional | Default | Description | Example/Values | Available since Version |
|---|---|---|---|---|---|---|
allowcreatecontainer | Boolean | yes | false | If the container does not exist, it will be created by the application. | true/false | 2.0.8 |
enableversioning | Boolean | yes | true | If the application (tia Core) is authorized to create containers and this parameter is additional enabled, the property "Enable ImmutableVersioning" is set. The following customizing is mandatory for this > https://kgs-software.atlassian.net/wiki/spaces/WIKI/pages/1665826820/Azure#%5BinlineExtension%5DAzure-mit-versionierten-Blobs | true/false | 2.0.8 |
management.clientId | String | yes | Azure credentials to automatically create containers with the "Enable ImmutableVersioning" setting enabled.https://github.com/IBM/IBMDeveloper-recipes/blob/main/how-to-procure-tenant-id-client-id-and-client-secret-key-to-connect-to-microsoft-azure-data-lake-storage-gen2/index.md | 2.0.8 | ||
management.clientSecret | String | yes | 2.0.8 | |||
management.tentantId | String | yes | 2.0.8 | |||
management.subcriptionId | String | yes | 2.0.8 | |||
management.resourceGroupName | String | yes | 2.0.8 | |||
management.accountName | String | yes | 2.0.8 |
Configuration example
<Repo>.contentservice.azureblobstorev2.allowcreatecontainer=false <Repo>.contentservice.azureblobstorev2.enableversioning=true <Repo>.contentservice.azureblobstorev2.management.tenantId= <Repo>.contentservice.azureblobstorev2.management.clientSecret= <Repo>.contentservice.azureblobstorev2.management.clientId= <Repo>.contentservice.azureblobstorev2.management.subcriptionId= <Repo>.contentservice.azureblobstorev2.management.resourceGroupName= <Repo>.contentservice.azureblobstorev2.management.accountName=
Access is allowed by Access Keys or Shared Access Signature Keys. It is important that tia core can access Object and the container itself. More permissions are required when tia core should create containers.
Die Werte können anhand dieser Anleitung ermittelt/erstellt werden:
Da diese Version von Azure auch contrepinpath unterstützt und auch default aktiviert hat, genügt es manuell einen Container anzulegen und alle Repositories darüber laufen zu lassen. Die Grenzen z.B. für Speicher und Durchsatz liegen auf dem StorageAccount, und werden für alle Container in dem Account geteilt. Die Grenzen von Azure Storage Accounts sind hier einsehbar: https://learn.microsoft.com/en-us/azure/storage/common/scalability-targets-standard-account?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json
Konfigurationsparameter in der repository.cfg
<Repo>.contentservice.type = azureblobstorev2 <Repo>.contentservice.azureblobstorev2.connectionstring=DefaultEndpointsProtocol=http;AccountName=devstoreaccount1;AccountKey=Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;TableEndpoint=http://127.0.0.1:10002/devstoreaccount1; <Repo>.contentservice.azureblobstorev2.container=test-repo #<Repo>.contentservice.azureblobstorev2.invalidcharacters= #default: #<Repo>.contentservice.azureblobstorev2.calculatestreamhash= #default: true #<Repo>.contentservice.azureblobstorev2.contrepinpath= #default: true #<Repo>.contentservice.azureblobstorev2.cleanversions= #default:true #<Repo>.contentservice.azureblobstorev2.region= #default:azure #<Repo>.contentservice.azureblobstorev2.minparallelsize= #default:4194304 #<Repo>.contentservice.azureblobstorev2.maxconcurrency= #default:2 #<Repo>.contentservice.azureblobstorev2.blocksize= #default:4194304 #<Repo>.contentservice.azureblobstorev2.singleuploadsize= #default:4194304
Überlegung zu blocksize und maxconcurrency
Informationen von Microsoft: https://learn.microsoft.com/en-us/java/api/com.azure.storage.common.paralleltransferoptions?view=azure-java-stable#com-azure-storage-common-paralleltransferoptions-setmaxconcurrency(java-lang-integer)
Die singleuploadsize bis welcher Größe Daten “am Stück“ hochgeladen werden. blocksize und maxconcurrency beeinflussen die Geschwindigkeit bei Daten die größer singleuploadsize sind. Höhere Parallelität und blocksize führ zu höheren Bedarf an CPU und Memory. Es gilt blocksize * maxconcurrency * Anzahl paralleler Anfragen = Memoryverbrauch.
Die Namensregeln sind wie bisher, siehe Namensregeln.
Namensgebungsregeln:
Containernamen
Ein Containername muss ein gültiger DNS-Name sein und den folgenden Benennungsregeln entsprechen:
Container Namen müssen mit einem Buchstaben oder einer Zahl beginnen oder enden und dürfen nur Buchstaben, Ziffern und Bindestriche (-) enthalten.
Jedem Bindestrich (-) muss unmittelbar ein Buchstabe oder eine Zahl vorangehen und folgen von einem Buchstaben oder einer Zahl; zudem dürfen nicht mehrere Bindestriche direkt aufeinander folgen.
Der Containername darf ausschließlich Kleinbuchstaben enthalten.
Containernamen müssen zwischen 3 und 63 Zeichen lang sein.