5 cách cài đặt application server phổ biến

Lời giới thiệu

Có nhiều vấn đề cần phải cân nhắc khi quyết định dùng mô hình server nào cho application của bạn, chẳng hạn như hiệu suất, khả năng mở rộng, tính sẵn có, độ tin cậy, chi phí và dễ quản lý.

Dưới đây là phần trình bày về danh sách các thiết lập server phổ biến thường dùng, mỗi phần sẽ có một đoạn giải thích ngắn gọn bao gồm cả ưu điểm và nhược điểm giúp mọi người có cái nhìn tổng quát hơn về web server. Chú ý rằng các cách dưới đây có thể sử dụng kết hợp lẫn nhau, ngoài ra thì mỗi môi trường cũng có yêu cầu khác nhau, nên có thể phần trình bày sẽ không chính xác hoàn toàn.

1. Tất cả trong một server

Tất cả phần mềm đều được đặt trên một máy chủ duy nhất. Với một application điển hình thì chúng sẽ bao gồm web server, application server và database server. Một biến thể phổ biến của cách cài đặt này là gói LAMP, viết tắt của Linux, Apache, MySQL và PHP, tất cả trên một server.

Trường hợp sử dụng: Khi cần để cài đặt application một cách nhanh chóng, đây là phần cài đặt cơ bản nhất có thể, nhưng rất khó mở rộng cũng như tách biệt các thành phần trong application với nhau.

Ưu điểm:

• Đơn giản.

Nhược điểm:

• Application và database sử dụng chung phần resources của server (CPU, bộ nhớ, I/O…) cho nên ngoài việc hiệu suất kém ra thì còn có thể làm cho việc xác định vấn đề trở nên khó khăn hơn.

• Khó mở rộng.

2. Tách biệt với server database

Các hệ thống quản lý cơ sở dữ liệu (DBMS) được tách ra khỏi phần còn lại của môi trường để loại bỏ các tranh chấp tài nguyên giữa các ứng dụng và cơ sở dữ liệu, và có thể tăng cường bảo mật bằng cách đặt cơ sở dữ liệu trong một private network.

Trường hợp sử dụng: Dùng để cài đặt application một cách nhanh chóng, nhưng vẫn có thể tránh việc application và database cùng sử dụng chung resource của hệ thống.

Ưu điểm:

• Tầng application và database không tranh chấp cùng một tài nguyên của server (CPU, bộ nhớ, I/O,…).

• Có thể thêm tài nguyên cho server nếu cần mở rộng.

• Có thể tăng cường bảo mật bằng cách đặt database trong private network.

Nhược điểm:

• Cài đặt phức tạp hơn so với dùng một server.

• Vấn đề hiệu suất có thể phát sinh nếu giữa hai server có độ trễ lớn (như hai server có khoảng cách địa lý cách xa nhau), hoặc là băng thông quá thấp so với lượng dữ liệu truyền tải.

3. Load Balancer (Reverse Proxy)

Load balancer có thể được thêm vào một môi trường máy chủ để cải thiện hiệu suất và độ tin cậy bằng cách phân phối việc xử lý request trên nhiều máy chủ. Nếu một trong các máy chủ load balancer bị lỗi, các máy chủ khác sẽ xử lý lưu lượng gửi đến cho đến khi máy chủ lỗi bình thường trở lại. Nó cũng có thể được sử dụng để phục vụ cho nhiều ứng dụng thông qua cùng một tên miền và cổng, bằng cách sử dụng một layer 7 (layer application) reverse proxy.

Ví dụ về các phần mềm có khả năng cân bằng tải reverse proxy: HAProxy, Nginx, và Varnish.

Trường hợp sử dụng: hữu ích trong một môi trường đòi hỏi phải mở rộng quy mô bằng cách thêm nhiều máy chủ.

Ưu điểm:

• Có thể mở rộng bằng cách thêm nhiều máy chủ.

• Có thể chống lại các cuộc tấn công DDOS bằng cách hạn chế các kết nối của user đến một số lượng và tần số hợp lý.

Nhược điểm:

• Load balancer có thể trở thành một nút cổ chai hiệu suất nếu nó không có đủ nguồn lực, hoặc nếu nó được cấu hình kém.

• Có thể có những vấn đề cần phải xem xét như nơi thực hiện chấm dứt SSL và làm thế nào để xử lý đòi hỏi session.

• The load balancer có một điểm thất bại duy nhất là khi máy chủ load balancer lỗi thì cả hệ thống sẽ dừng hoạt động.

4. HTTP Accelerator (Caching Reverse Proxy)

Có thể giảm thời gian tải content từ server đến user thông qua một loạt các kỹ thuật như dùng HTTP accelerator hoặc caching HTTP reverse proxy. HTTP accelerator sẽ lưu trữ phần content trả về từ application vào trong bộ nhớ, sau này nếu có yêu cầu đến nội dung tương tự như vậy thì HTTP Accelerator chỉ việc lấy trong bộ nhớ và trả về cho người dùng mà không cần phải có những tương tác không cần thiết với web server.

Ví dụ về các phần mềm có khả năng tăng tốc HTTP: Varnish, Squid, Nginx.

Trường hợp sử dụng: hữu ích trong một môi trường với các ứng dụng web động có nội dung nặng, hoặc với nhiều resource được truy cập thường xuyên.

Ưu điểm:

• Tăng hiệu suất trang web bằng cách giảm tải CPU trên máy chủ web, thông qua bộ nhớ đệm và nén, do đó làm tăng khả năng sử dụng

• Có thể được sử dụng như là hệ thống load balancer.

• Một số phần mềm caching có thể bảo vệ chống lại các cuộc tấn công DDOS.

Nhược điểm:

• Yêu cầu phải điều chỉnh để có được hiệu suất tốt nhất.

• Nếu tỷ lệ tái sử dụng bộ nhớ cache thấp thì có thể làm giảm hiệu suất.

5. Master-Slave Database Replication

Một cách để cải thiện hiệu suất của một hệ thống cơ sở dữ liệu mà số lần đọc được thực hiện nhiều hơn so với viết, chẳng hạn như là một CMS, là sử dụng master-slave database replicate. Master-slave replicate đòi hỏi một master và một hoặc nhiều hơn các nút slave. Trong thiết lập này, việc cập nhật dữ liệu sẽ được gửi cho nút master và việc đọc dữ liệu sẽ được phân phối trên tất cả các nút.

Trường hợp sử dụng: Tốt trong việc tăng cường hiệu suất đọc dữ liệu từ database của application.

Dưới đây là ví dụ về cài đặt master-slave replication với một nút slave:

Ưu điểm:

• Cải thiện hiệu suất đọc dữ liệu bằng cách phân tán việc đọc đến các nút slave.

• Có thể cải thiện hiệu suất thông qua việc chỉ dùng nút master cho việc ghi dữ liệu (gần như không dùng nút master cho việc đọc dữ liệu).

Nhược điểm:

• Application cần phải có một cơ chế để xác định các nút database nào dùng để ghi và cái nào dùng để đọc.

• Việc cập nhật data cho các nút slave là không đồng bộ, do đó, nên có khả năng dữ liệu application đọc được không phải là mới nhất.

• Nếu nút master bị lỗi, thì việc cập nhật dữ liệu có thể bị gián đoạn cho đến khi vấn đề được giải quyết.

• Không có trường hợp dự phòng cho việc nút master bị lỗi.

Ví dụ: Kết hợp tất cả

Có thể dùng load balancer trên caching server ngoài application server và dùng database replication trên cùng một môi trường. Mục đích của việc kết hợp này là để đạt được những kết quả tối ưu nhất mà không gặp nhiều khó khăn. Dưới đây là một mô hình ví dụ về môi trường của server:

Hãy giả định rằng việc load balancer được cấu hình để nhận dạng những yêu cầu đến những tài nguyên tĩnh (như hình ảnh, css, javascript…), gửi những request trực tiếp đến caching server và gửi những request còn lại đến application server.

Dưới đây là một mô tả về những gì sẽ xảy ra khi người dùng gửi một request đến các nội dung động:

1. Người dùng gửi request đến các tài nguyên động đến https://example.com/ (load balancer).

2. Load balancer gửi request to app-backend.

3. App-backend đọc dữ liệu từ database và trả nội dung về cho load balancer.

4. Load balancer trả dữ liệu lấy được về cho người dùng.

Nếu người dùng request các nội dung tĩnh:

1. Load balancer kiểm tra cache-backend xem nội dung được yêu cầu đã có (cache-hit) hay chưa (cache-miss).

2. Nếu cache-hit: trả về nội dung được yêu cầu cho load balancer và chuyển đến  bước 7. Nếu cache-miss: cache server sẽ chuyển request đến app-backend, thông qua load balancer.

3. Load balancer chuyển request cho app-backend.

4. App-backend đọc dữ liệu từ database sau đó trả nội dung được yêu cầu về cho load balancer.

5. Load balancer chuyển nội dung đó cho cache-backend.

6. Cache-backend caches nội dung và trả nó về cho load balancer.

7. Load balancer trả nội dung được yêu cầu về cho user.

Môi trường này vẫn có hai điểm thất bại (load balancer và master database), nhưng nó cung cấp tất cả các lợi ích đáng tin cậy và hiệu suất đã được mô tả trong mỗi phần ở trên.

Kết luận

Bây giờ bạn đã quen thuộc với một số cách cài đặt server cơ bản, bạn cần phải có một ý tưởng tốt về những cách bạn sẽ sử dụng cho application của bạn. Nếu bạn đang tìm cách cải thiện hiệu suất server của bạn, hãy nên thử từ những cách đơn giản trước sau đó mới chuyển dần lên những cách phức tạp hơn.

Theo Mitchell Anicas – Digital Ocean