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 |
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 |
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 |
<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.allowcreatecontainer = false <Repo>.contentservice.azureblobstorev2.enableversioning = 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 mit versionierten Blobs
Die Ablage hier ist sehr ähnlich der Ablage in S3, es wird sowohl Objekt-individuelle Retention als auch LegalHold unterstützt.
Um die Funktion nutzen zu können, ist es notwendig einen Container mit der Option “version-level immutability” anzulegen. Siehe: Configure immutability policies for blob versions
Dies kann entweder generell im StorageAccount erfolgen, durch einen manuell angelegten Container oder über tia core mit entsprechender Konfiguration.
Access ist 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.
Wenn tia core selbst einen Container anlegen soll und dort individuell die Versionsfunktion aktivieren soll, sind folgende Einstellungen in der repository.cfg notwendig:
<Repo>.contentservice.azureblobstorev2.allowcreatecontainer=true #default:false <Repo>.contentservice.azureblobstorev2.enableversioning=true #default: 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=
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.