Home > Workload Solutions > SQL Server > White Papers > SQL Server 2019 Containers on Linux > Step 6: Configure a storage volume and connect it to the container
Containers that are used for microservices can often function without the need for persistent storage. Database servers such as SQL Server most often require persistent storage for critical data that must be preserved after the container has been shut down or deleted.
Three steps are required for creating and mounting a persistent volume from XtremIO X2 to the PowerEdge server:
When creating storage volumes on the XtremIO X2 array, administrators never have to make choices that are typically associated with traditional storage arrays, such as defining the number and type of drives for a storage pool. The administrators also do not have to choose a RAID protection type. For databases that span multiple XtremIO X2 volumes, consider creating a consistency group on the array. A consistency group is a set of volumes that are grouped to ensure write consistency when a snapshot is requested or the disks in the group are replicated.
Note: Although provisioning XtremIO X2 storage is fast and easy, the process requires the coordination between the storage administrator and the developer. Experience shows that delays often occur in this coordination of provisioning containers with external storage and, thus, affect development. In the second use case, we explore how teams can use Kubernetes and the CSI plug-in for XtremIO X2 to solve these challenges.
For this first use case, the storage administrator manages the storage without the aid of Kubernetes and the CSI plug-in. Therefore, after configuring and connecting the XtremIO X2 storage to the PowerEdge server, the storage administrator must manually connect the storage volumes to the SQL Server container. The administrator can do so by using Docker volumes or Linux bind mounts.
Docker volumes provide the ability to define storage to be managed by a Docker container. The storage is maintained under the Docker directory structure (for example, /var/lib/docker/volumes) and can be managed from the Docker CLI or through the Docker API. The volumes are managed by the Docker engine and are isolated from direct access by the host, as shown in the following figure:
Figure 3. Docker volumes
Advantages of Docker data volumes include:
For a full list of benefits, see Volumes in the Docker documentation.
In this case, the Linux administrator uses Linux bind mounts to connect a SQL Server container to XtremIO X2 storage that has already been provisioned to the server. As mentioned in the Docker guide, bind mounts are fast, which makes this method ideal for attaching storage to a container. As shown in the following figure, bind mounts can be anywhere in the host operating system and are not managed by Docker:
Figure 4. Bind mount
The Linux administrator runs the following commands to mount the XtremIO X2 sdbl directory to the SQL Server container:
$ cd /sdb1
$ mkdir mssql-data-dir
$ mount -o bind /sdb1/mssql-data-dir /var/opt/
For persistence after reboots, the Linux administrator updates the /etc/fstab file with the bind mount as follows:
/var/opt /sdb1/mssql-data-dir none bind 0 0
Then the Kubernetes administrator creates the SQL volume with the -v parameter:
$ docker run --name sqlservername -e “ACCEPT_EULA” -e “MSSQL_SA_PASSWORD=password” -v volumename:/var/opt/mssql-data-dir -p 1433:1433 -d localhost:5000/sql2019
Because bind mounts are external to Docker, an external process or person can modify the files. For SQL Server on Linux, the Linux administrator secures the directory and its files as follows:
chown -R mssql /mssql-data-dir
chgrp -R mssql /mssql-data-dir
chmod -R 750 mssql /mssql-data-dir
To show how the XtremIO X2 array can be used to quickly provide storage to a SQL Server container, we use the AdventureWorks database. AdventureWorks, created by Microsoft, is a sample database that is based on a fictitious multinational manufacturing company called AdventureWorks Cycles. The AdventureWorks database, which can be installed by restoring a database backup or by attaching a datafile, simulates an OLTP application and can be used for learning how SQL Server works.
In our case, we put a copy of the AdventureWorks database on the XtremIO X2 array. Integrated Copy Data Management (iCDM) tracks copies of data on XtremIO X2 and enables deduplication. Thus, by using XtremIO Virtual Copies to create an associated copy of our AdventureWorks database, the copy takes a fraction of space on the array. Using XtremIO Virtual Copies enables us to create copies quickly and provision multiple copies from one primary AdventureWorks database.