1, the advantages of distributed
1.minio distributed introduction
MinIO in distributed mode allows you to drive a plurality (or even on a different computer) into an object storage server. Since the drive distributed across multiple nodes, distributed MinIO can withstand multiple node failures, but still ensures complete data protection.
MinIO in distributed mode helps you to set up high-availability storage systems through a single object storage deployment. With distributed MinIO, regardless of how storage location in the network, you can optimize the use of storage devices.
2. Data protection
3. High Availability
If the managed disk server is offline, the server will shut down independent MinIO. In contrast, distributed as long as the n / 2 or more disks online, with n disks MinIO setting will make your data safe. However, you need at least (n / 2 + 1) statutory disk to create new objects.
For example, even if up to eight servers is offline, a set of distributed MinIO 16 nodes (each node has a disk 16) can continue to provide documentation. However, you need to be online at least nine servers to create new objects.
4. limit
And MinIO as in standalone mode, each tenant distributed MinIO is limited to a minimum of 2 up to 32 server. The number of disks on the server does not have these restrictions. If you need to set up a multi-tenant, you can easily start multiple instances of the MinIO coordination tools (such as Kubernetes, Docker Swarm, etc.) management.
Please note distributed MinIO, as long as compliance with restrictions on the number of nodes and drives can handle. For example, you can have two nodes, each four drives, four nodes for each drive 4, eight nodes per two drives 32 for each server 64 drives, and so on.
5. ensure consistency
After MinIO follow strict writing and reading lists read / model of consistency all inputs and outputs are distributed and standalone mode operation.
2, Helm Chart deploy MinIO
Prerequisites:
1. a cluster k8s
2. Have helm environment
1. Deploy minio
Creating pv minio needed
#vim pv1.yaml apiVersion: v1 kind: PersistentVolume metadata: name: minio-pv1 spec: capacity: storage: 10Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /helm/minio/pv1
As used herein, it is hostpath, create the appropriate directories in the worker nodes.
# First pulled in the local installation helm pull stable/minio -zxvf of minio-3.0.4.tgz helm install minio ./minio # Or directly helm install minio stable/minio
View pod
3. Log in to access minio
Default parameters:
Access the web interface
access Key and secret Key is the default, the configuration in FIG.
kubectl get deploy minio -oyaml view the associated Key
Add gitlab of yaml file
kubectl edit deploy gitlab-gitlab-ce
- name: MINIO_ACCESS_KEY valueFrom: secretKeyRef: key: accesskey name: minio - name: MINIO_SECRET_KEY valueFrom: secretKeyRef: key: secretkey name: minio
View the normal state
Login gotlab create a file
Delete the original pod
gitlab the pod start-up time is a bit long, and so you can start to see complete access interface
