Container Persistence in Modern IT Infrastructure
Explore the concept of container persistence in the context of modern IT infrastructure, covering topics such as data storage options, maintaining persistence in stateless services, and the evolution of microservices architecture.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
To persist, or not to persist (container data), that is the question John Griffith, SolidFire Kenneth Hui, Rackspace Shamail Tahir, IBM
Presenters Kenneth Hui OpenStack Evangelist Rackspace @kenhuiny
What is a container? Defines available operations, exec environment, FS setup, resource reservations, etc. LXC runC (libcontainer) Container Format Changes made to the running containers are stored in R/W layer Container R/W Layer (0MB) Filesystem Layer 2 (6MB) UnionFS Imag e Layer 1 (120MB) Images consist of read-only layers that create the aggregated contents/config of container at initialization cgroups namespaces OS Features Used to provide container specific view of the system (isolated PID, net, user, etc. namespaces) Cgroups are used to limit resources available to the container (RAM, CPU, Block I/O)
Introduction to micro services UI API API UI UI API Container Container Container Container Application Logic Logic X Logic Y Logic Z Database Container Container Container Single Instance Data Container Microservices Architecture Monolith
So why a whole session on persistence? This service is stateless and I don t care if the data goes *poof* Container R/W Layer I will create a new image to retain the new content Data in this layer is ephemeral and will be discarded when the container is terminated ( - ) I m sure there are better ways to maintain persistence
Numerous persistence options Local Storage Remote Storage Distributed Storage Data stores Container Container Container Container Container Container Container Container Host Host Host Host Host Host SDS Database Dedicated Storage Storage
Are you sure you are doing this right? ONE DOES NOT SIMPLY ATTACH STORAGE TO A CONTAINER Don t treat your containers like lightweight virtual machines Don t attach volumes to all your containers Don t use traditional SAN Storage
Dont treat your containers like lightweight VMs Large images are anchors Containers shouldn t be treated like pets
Dont attach volumes to all your containers You lose benefits of ephemeralness You reduce your elasticity
Dont use traditional SAN storage You limit your scalability You create SPOF
There is a better way to do this Do use loosely coupled backend services Do use persistent storage only when necessary Do use distributed storage
Do use loosely coupled backend services Use object storage for file data Use DB-as-a-Service for data stores
Do use persistent storage only when necessary Focus on keeping containers stateless Use for data stores that may be difficult to replicate
