Overlay filesystem trong container là gì? Cơ chế Copy-on-Write và Whiteout

Nếu bạn từng thắc mắc tại sao Docker image lại nhẹ và khởi động nhanh đến vậy, hoặc tại sao dung lượng máy chủ cứ đầy dần dù đã xóa file, Overlay filesystem chính là cơ chế đứng sau. Hãy cùng Viettel IDC giải mã Overlay filesystem trong container là gì và cách thức hoạt động trong bài viết sau.

Overlay Filesystem (OverlayFS) là gì?

Overlay Filesystem (thường gọi là OverlayFS) là hệ thống tệp phân lớp (union filesystem) cho phép chồng nhiều thư mục lên nhau và hiển thị chúng thành một thư mục thống nhất. Trong Container (như Docker), nó giúp tiết kiệm dung lượng lưu trữ và khởi tạo container tức thì nhờ cơ chế chia sẻ các lớp cơ sở.

Trong thực tế, nếu bạn kiểm tra hệ thống bằng lệnh docker info, bạn sẽ không thấy tên gọi chung "OverlayFS", mà là overlay2. Từ phiên bản Docker Engine 18.09, Docker đã chính thức khai tử driver overlay đời đầu để chuyển sang dùng mặc định overlay2. Nguyên nhân chính là do phiên bản cũ mắc một điểm yếu chí mạng: tiêu tốn quá nhiều Inode (mã định danh tệp) dẫn đến lỗi sập máy chủ dù ổ cứng vẫn còn trống.

Tại sao các nền tảng Container lại sử dụng OverlayFS?

Các nền tảng Container như Docker, Podman hay Kubernetes coi OverlayFS (đặc biệt là phiên bản overlay2) là "xương sống" trong việc quản lý hệ thống tệp tin. Công nghệ này giải quyết xuất sắc ba bài toán lớn nhất của hạ tầng máy chủ: tốc độ, dung lượng lưu trữ và tài nguyên RAM. Dưới đây là những lý do cốt lõi khiến OverlayFS trở thành tiêu chuẩn cho công nghệ container hóa:

- Tiết kiệm dung lượng lưu trữ (Storage Efficiency) cực hạn: Hàng trăm container có thể chạy trên cùng một máy chủ và dùng chung một Image gốc (Base Image). Thay vì nhân bản hệ điều hành lên hàng trăm lần như máy ảo (Virtual Machine) truyền thống, OverlayFS cho phép các container dùng chung lớp tệp tin gốc. Mỗi container chỉ tiêu tốn thêm một lượng rất nhỏ dung lượng cho các dữ liệu mới phát sinh ở lớp trên cùng.

- Tốc độ khởi động tính bằng mili-giây (Instant Startup): Khi khởi chạy một container, Docker không hề sao chép bất kỳ dữ liệu vật lý nào. Hệ thống chỉ yêu cầu OverlayFS thực hiện thao tác gắn kết (Union Mount) các thư mục lại với nhau ở cấp độ nhân Linux. Nhờ bỏ qua quá trình ghi chép I/O, thời gian khởi động container diễn ra gần như ngay lập tức.

- Tối ưu hóa bộ nhớ RAM (Page Cache Sharing): OverlayFS chia sẻ bộ nhớ đệm vô cùng hiệu quả. Khi nhiều container cùng đọc một tệp tin dùng chung (ví dụ: thư viện libc.so), nhân Linux chỉ tải tệp đó vào bộ đệm RAM (Page Cache) đúng một lần duy nhất. Điều này giúp hệ thống tiết kiệm hàng GB RAM khi vận hành kiến trúc Microservices quy mô lớn.

- Bảo vệ dữ liệu gốc thông qua cơ chế Copy-on-Write (CoW): Dữ liệu ở Image gốc luôn ở trạng thái bất biến (chỉ đọc). Khi một container cần chỉnh sửa tệp tin hệ thống, nó sẽ âm thầm sao chép tệp đó sang phân vùng riêng của mình để thao tác. Dù container có bị lỗi hoặc nhiễm mã độc, Image gốc và các container khác vẫn được cách ly và an toàn tuyệt đối.

- Tăng tốc quá trình Build Image trong CI/CD: Trong quá trình đóng gói ứng dụng, OverlayFS lưu trữ từng bước lệnh (RUN, COPY) thành các lớp (layers) riêng biệt. Nếu có sự thay đổi mã nguồn, hệ thống chỉ cần tự động tải lại các lớp không đổi từ bộ nhớ cache và tiến hành build lại duy nhất lớp bị thay đổi, giúp rút ngắn tối đa thời gian triển khai.

Cấu trúc 3 thành phần cốt lõi của OverlayFS trong Docker

Để hệ thống tệp tin phân lớp hoạt động trơn tru, Docker sử dụng overlay2 với kiến trúc xếp chồng độc đáo. Cấu trúc này chia thành ba thành phần chính, phối hợp chặt chẽ để tối ưu dung lượng và bảo vệ dữ liệu gốc.

LowerDir (Thư mục lớp dưới - Chỉ đọc)

LowerDir là các lớp (layers) nền tảng tạo nên một Docker Image, bao gồm hệ điều hành, môi trường chạy và mã nguồn. Đặc tính cốt lõi của lớp này là bất biến và chỉ đọc (Read-Only). Dữ liệu tại đây không bao giờ bị thay đổi khi container hoạt động. Nhờ vậy, hàng trăm container có thể dùng chung một LowerDir gốc, giúp tiết kiệm tối đa dung lượng ổ cứng.

Chẳng hạn, nếu bạn khởi chạy 10 container từ Base Image Ubuntu (nặng khoảng 70MB), máy chủ của bạn vẫn chỉ tốn đúng 70MB dung lượng cho phần hệ điều hành, thay vì ngốn đến 700MB như cách nhân bản của máy ảo truyền thống.

UpperDir (Thư mục lớp trên - Đọc/Ghi)

UpperDir (hay Container Layer) là một thư mục trống nằm trên cùng, được Docker tự động tạo ra ngay khi khởi chạy container. Khác với lớp nền bên dưới, UpperDir cấp quyền Đọc và Ghi (Read/Write), là nơi lưu trữ vật lý cho mọi biến động dữ liệu khi ứng dụng hoạt động. 

Lấy ví dụ, khi một hệ thống Node.js bên trong container xuất ra file error.log, tệp tin này sẽ được ghi trực tiếp vào UpperDir. Tuy nhiên, lớp này có tính chất tạm thời gắn liền với vòng đời của container. Nếu bạn gõ lệnh docker rm để xóa container, file log kia cùng toàn bộ dữ liệu sinh ra ở lớp này sẽ bốc hơi vĩnh viễn (đó là lý do bạn cần dùng thêm Docker Volumes để lưu trữ lâu dài).

Merged (Góc nhìn hợp nhất - View)

Merged không lưu trữ dữ liệu vật lý, mà hoạt động như một điểm gắn kết ảo (mount point) – kết quả đầu ra cuối cùng của thuật toán OverlayFS. Ứng dụng trong container không hề nhận biết được sự tách biệt của các lớp bên dưới; chúng chỉ nhìn qua Merged và thấy một hệ thống file duy nhất, hoàn chỉnh. Cơ chế này hoạt động theo nguyên tắc chồng lấp.

Ví dụ: LowerDir chứa file gốc config.json. Khi bạn vào container sửa file này, bản mới sẽ lưu ở UpperDir. Lớp Merged sẽ tự động ẩn bản gốc đi, chỉ cung cấp bản đã sửa ở UpperDir cho ứng dụng đọc.

Cơ chế Copy-on-Write và Whiteout của Overlay filesystem trong container là gì

Cơ chế hoạt động của OverlayFS trong container dựa trên 2 nguyên lý cốt lõi là Copy-on-Write (CoW) và Whiteout để quản lý mọi sự thay đổi dữ liệu mà tuyệt đối không làm ảnh hưởng đến Image gốc. Cụ thể, OverlayFS xử lý 4 thao tác tệp tin cơ bản như sau:

- Khi Đọc tệp tin (Read): Quy trình tìm kiếm diễn ra từ trên xuống dưới. OverlayFS ưu tiên tìm tệp tin ở lớp UpperDir trước, nếu không có mới rà soát tiếp xuống lớp LowerDir để trả về kết quả.

- Khi Tạo mới (Create): Mọi dữ liệu mới sinh ra trong quá trình container hoạt động (ví dụ: file log, ảnh người dùng tải lên) đều được ghi vật lý trực tiếp vào lớp UpperDir.

- Khi Sửa tệp tin (Copy-on-Write): Khi container cần sửa một tệp tin đang nằm ở lớp LowerDir (chỉ đọc), OverlayFS sẽ lập tức sao chép (copy) tệp đó lên lớp UpperDir, sau đó ghi đè (write) nội dung sửa đổi lên bản sao này. Bản gốc bên dưới vẫn được bảo toàn nguyên vẹn.

- Khi Xóa tệp tin (Whiteout): Vì không có quyền xóa dữ liệu ở lớp LowerDir, OverlayFS sẽ tạo ra một tệp đánh dấu (gọi là whiteout) ở lớp UpperDir. Khi lớp hiển thị (Merged) nhìn thấy tệp whiteout này, nó sẽ tự động "che khuất" file gốc đi, khiến container hiểu rằng tệp tin đó đã thực sự bị xóa.

Tại sao lệnh xóa file lại làm Docker Image nặng hơn?

Việc thêm lệnh xóa tệp (ví dụ: RUN rm -rf /var/cache) ở cuối Dockerfile không những không giảm mà còn làm Image phình to hơn. Nguyên nhân đến từ cơ chế phân lớp của OverlayFS:

- Mỗi lệnh RUN tạo ra một lớp (layer) mới.

- Vì các lớp cũ (LowerDir) là chỉ đọc, OverlayFS không thể xóa tệp vật lý tại đây.

- Hệ thống chỉ tạo ra tệp "whiteout" ở lớp mới nhất để che đi tệp cũ.

Hệ quả là tệp rác gốc vẫn nằm vĩnh viễn trong Image, cộng thêm dung lượng của lớp mới sinh ra khiến tổng kích thước tăng lên. Để giải quyết dứt điểm bài toán làm sao giảm size Docker image với các dự án chứa công cụ biên dịch nặng (như Node_modules, C++ hay Golang), bạn cần một phương pháp tối ưu triệt để hơn.

Ưu điểm và nhược điểm của Overlay filesystem

OverlayFS là nền tảng cốt lõi của công nghệ container, nhưng nó không phải là giải pháp hoàn hảo cho mọi mục đích. Dưới đây là những điểm mạnh và hạn chế thực tế của hệ thống này:

Ưu điểm

- Tiết kiệm dung lượng lưu trữ cực hạn: Nhờ cơ chế dùng chung lớp nền (Base Image), hàng trăm container có thể chạy mà chỉ tốn thêm vài MB dung lượng ổ cứng.

- Khởi động siêu tốc (Mili-giây): Bỏ qua quá trình sao chép dữ liệu vật lý khi khởi tạo, container có thể chạy gần như ngay lập tức.

- Tối ưu RAM (Page Cache): Linux kernel chỉ tải các file dùng chung lên bộ nhớ đệm đúng một lần, chia sẻ cho tất cả container.

Nhược điểm

- Giảm hiệu năng khi ghi dữ liệu lớn (I/O Bottleneck): Do cơ chế Copy-on-Write, nếu container muốn sửa một file rất nặng (ví dụ file database 5GB) từ lớp chỉ đọc, OverlayFS phải tốn thời gian copy toàn bộ 5GB đó lên lớp trên trước khi sửa. Đó là lý do các chuyên gia luôn cấm chạy Database trực tiếp trên OverlayFS mà phải dùng Docker Volumes.

- Nguy cơ cạn kiệt Inode: Dù tối ưu dung lượng, nhưng nếu container sinh ra hàng triệu file nhỏ gọn liên tục (như file cache, session), hệ thống có thể bị hết Inode trước khi hết dung lượng đĩa cứng, dẫn đến lỗi treo hệ thống.

- Không hỗ trợ môi trường Windows: OverlayFS phụ thuộc hoàn toàn vào nhân Linux. Trên Windows Server, bạn buộc phải dùng công nghệ thay thế khác.

OverlayFS và khác gì với filesystem thông thường?

OverlayFS là một hệ thống tệp tin phân lớp (layered filesystem), cho phép xếp chồng nhiều thư mục độc lập lên nhau để tạo thành một góc nhìn hợp nhất duy nhất cho ứng dụng. Điểm khác biệt cốt lõi giữa OverlayFS và các hệ thống tệp tin truyền thống (như EXT4, NTFS) nằm ở kiến trúc lưu trữ đa lớp và cơ chế xử lý dữ liệu hoàn toàn không ghi đè lên tệp gốc.

Kết luận

Hiểu rõ về Overlay filesystem trong container là gì giúp bạn tối ưu hóa hiệu năng hệ thống ngay từ nội tại. Tuy nhiên, để quản lý image tập trung và bảo mật cho môi trường sản xuất, bạn cần một nền tảng lưu trữ chuyên biệt. Nếu đang tìm kiếm giải pháp tối ưu cho nhu cầu này, hãy tham khảo ngay Viettel Container Registry để triển khai ứng dụng mượt mà và an toàn cho doanh nghiệp ngay hôm nay.