GALAXY TECH
Chuyên gia Công nghệ
Thứ tư, 11/02/2015 | 00:00 GMT+7

5 cách cải thiện thiết lập server ứng dụng web sản xuất của bạn

Sau khi ứng dụng của bạn được cài đặt và chạy trong môi trường server cloud , bạn có thể tự hỏi làm thế nào bạn có thể cải thiện môi trường server của bạn để tạo bước nhảy vọt từ “nó hoạt động” sang môi trường production chính thức. Bài viết này sẽ giúp bạn bắt đầu lập kế hoạch và triển khai môi trường production bằng cách tạo ra một định nghĩa lỏng lẻo về "sản xuất", trong bối cảnh ứng dụng web trong môi trường server cloud và bằng cách hiển thị cho bạn một số thành phần mà bạn có thể thêm vào kiến trúc để thực hiện chuyển đổi.

Với mục đích của phần trình diễn này, hãy giả sử rằng ta đang bắt đầu với cài đặt tương tự như cài đặt được mô tả trong 5 Cài đặt server chung , giống như môi trường hai server này chỉ phục vụ một ứng dụng web:

Cài đặt ứng dụng

Cài đặt thực tế của bạn có thể đơn giản hơn hoặc phức tạp hơn, nhưng các ý tưởng và thành phần chung được thảo luận ở đây sẽ áp dụng cho mọi môi trường server ở một mức độ nào đó.

Hãy bắt đầu với việc xác định ý của ta khi nói “ môi trường production ”.

Môi trường production là gì?

Theo nghĩa chung, môi trường server cho ứng dụng web bao gồm phần cứng, phần mềm, dữ liệu, kế hoạch hoạt động và nhân sự cần thiết để duy trì hoạt động của ứng dụng. Môi trường production thường đề cập đến môi trường server được thiết kế và triển khai với sự cân nhắc tối đa về mức độ chấp nhận được của các yếu tố sau:

  • Tính khả dụng : Khả năng user dự định có thể sử dụng ứng dụng trong những giờ được quảng cáo. Tính khả dụng có thể bị gián đoạn bởi bất kỳ lỗi nào ảnh hưởng đến thành phần quan trọng đủ nghiêm trọng (ví dụ: ứng dụng bị treo do lỗi, thiết bị lưu trữ database bị lỗi hoặc administrator hệ thống vô tình tắt server ứng dụng).

Một cách để thúc đẩy tính sẵn sàng là giảm số lượng điểm lỗi đơn lẻ trong môi trường. Ví dụ: sử dụng IP tĩnh và dịch vụ chuyển đổi dự phòng giám sát đảm bảo user chỉ truy cập các bộ cân bằng tải lành mạnh. Để tìm hiểu thêm, hãy đọc phần Cách sử dụng IP nổi và bài viết này về cân bằng tải .

  • Khả năng thu hồi: Khả năng phục hồi một môi trường ứng dụng trong trường hợp lỗi hệ thống hoặc mất dữ liệu. Nếu một thành phần quan trọng bị lỗi và không thể khôi phục được, tính khả dụng sẽ không tồn tại. Cải thiện khả năng bảo trì , một khái niệm liên quan, làm giảm thời gian cần thiết để thực hiện một quy trình khôi phục nhất định trong trường hợp có sự cố, và do đó có thể cải thiện tính khả dụng trong trường hợp có sự cố

  • Hiệu suất : Ứng dụng hoạt động như mong đợi dưới mức tải trung bình hoặc cao điểm (ví dụ: nó đáp ứng hợp lý). Mặc dù rất quan trọng đối với user của bạn, nhưng hiệu suất chỉ quan trọng nếu ứng dụng có sẵn

Hãy dành một chút thời gian để xác định các mức có thể chấp nhận được cho từng mục vừa được đề cập, trong bối cảnh ứng dụng của bạn. Điều này sẽ khác nhau tùy thuộc vào tầm quan trọng và tính chất của ứng dụng được đề cập. Ví dụ: có thể chấp nhận được việc một blog cá nhân phục vụ ít khách truy cập thỉnh thoảng bị ngừng hoạt động hoặc hoạt động kém, miễn là blog đó có thể được khôi phục, nhưng cửa hàng trực tuyến của một công ty nên đạt điểm rất cao trên toàn diện. Tất nhiên, sẽ rất tuyệt nếu đạt được 100% trong mọi hạng mục, cho mọi ứng dụng, nhưng điều đó thường không khả thi do hạn chế về thời gian và tiền bạc.

Lưu ý ta chưa đề cập đến (a) độ tin cậy của phần cứng, xác suất mà một thành phần phần cứng nhất định sẽ hoạt động bình thường trong một khoảng thời gian nhất định trước khi bị lỗi hoặc (b) bảo mật là các yếu tố. Điều này là do ta đang giả định (a) các server cloud bạn đang sử dụng nói chung là tin cậy nhưng có khả năng bị lỗi (khi chúng chạy trên các server vật lý) và (b) bạn đang tuân theo các phương pháp bảo mật tốt nhất trong khả năng của bạn — nói một cách đơn giản, chúng nằm ngoài phạm vi của bài viết này. Tuy nhiên, bạn nên biết rằng độ tin cậy và bảo mật là những yếu tố có thể ảnh hưởng trực tiếp đến tính khả dụng và cả hai đều có thể góp phần vào nhu cầu về khả năng khôi phục.

Thay vì chỉ cho bạn quy trình từng bước để tạo môi trường production , điều không thể thực hiện được do nhu cầu và tính chất khác nhau của mọi ứng dụng, ta sẽ trình bày một số thành phần hữu hình có thể sử dụng để chuyển cài đặt hiện tại của bạn thành môi trường production .

Ta hãy xem xét các thành phần!

1. Hệ thống backup

Hệ thống backup sẽ cấp cho bạn khả năng tạo các bản backup định kỳ dữ liệu và khôi phục dữ liệu từ các bản backup . Các bản backup cũng cho phép khôi phục dữ liệu về trạng thái trước đó, trong trường hợp vô tình xóa hoặc sửa đổi không mong muốn, có thể xảy ra do nhiều nguyên nhân bao gồm cả lỗi của con người. Tất cả phần cứng máy tính đều có khả năng bị hỏng vào một thời điểm nào đó, có thể gây mất dữ liệu. Với ý nghĩ này, bạn nên duy trì các bản backup gần đây của tất cả dữ liệu quan trọng của bạn .

Cần thiết cho production ? Đúng. Hệ thống backup có thể giảm thiểu tác động của việc mất dữ liệu, điều này cần thiết để đạt được khả năng khôi phục và do đó, hỗ trợ tính khả dụng trong trường hợp mất dữ liệu — nhưng nó phải được sử dụng cùng với các kế hoạch khôi phục vững chắc, sẽ được thảo luận trong phần tiếp theo. Lưu ý các bản backup dựa trên ảnh chụp nhanh của DigitalOcean có thể không đủ cho tất cả các nhu cầu backup của bạn, vì nó không phù hợp để tạo bản backup database đang hoạt động và các ứng dụng khác có I / O ghi vào đĩa cao — nếu bạn chạy các loại ứng dụng này, hoặc muốn tính linh hoạt hơn trong việc lập lịch backup , hãy đảm bảo sử dụng một hệ thống backup khác chẳng hạn như Bacula.

Hệ thống backup mẫu

Sơ đồ trên là một ví dụ về hệ thống backup cơ bản. Server backup nằm trong cùng trung tâm dữ liệu với các server ứng dụng, nơi các bản backup ban đầu được tạo. Sau đó, các bản backup ngoài trang web được thực hiện tới một server trong một trung tâm dữ liệu khác đảm bảo dữ liệu được bảo toàn trong trường hợp xảy ra thảm họa thiên nhiên.

Cân nhắc

  • Lựa chọn backup : Dữ liệu mà bạn sẽ backup . Tối thiểu, hãy backup mọi dữ liệu mà bạn không thể tái tạo một cách tin cậy từ một nguồn thay thế
  • Lịch trình backup : Khi nào và tần suất bạn sẽ thực hiện backup toàn bộ hoặc tăng dần. Cần phải xem xét đặc biệt khi backup một số loại dữ liệu, chẳng hạn như database đang hoạt động, có thể ảnh hưởng đến lịch trình backup của bạn
  • Thời gian lưu giữ dữ liệu: Bạn sẽ giữ các bản backup của bạn trong bao lâu trước khi xóa chúng
  • Dung lượng đĩa để backup : Sự kết hợp của ba mục trước đó ảnh hưởng đến dung lượng ổ đĩa mà hệ thống backup của bạn sẽ yêu cầu.Tận dụng khả năng nén và backup gia tăng để giảm dung lượng ổ đĩa mà các bản backup của bạn yêu cầu
  • Backup ngoài địa điểm: Để bảo vệ các bản backup của bạn khỏi các thảm họa local , trong một trung tâm dữ liệu cụ thể, bạn nên duy trì một bản backup của bạn ở một vị trí địa lý riêng biệt. Trong sơ đồ trên, các bản backup của NYC3 được sao chép sang SFO1 cho mục đích này
  • Kiểm tra khôi phục backup : Kiểm tra định kỳ quá trình khôi phục backup của bạn đảm bảo rằng các bản backup của bạn hoạt động bình thường

2. Kế hoạch phục hồi

Kế hoạch khôi phục là một tập hợp các thủ tục được lập thành văn bản để khôi phục từ các lỗi tiềm ẩn hoặc lỗi quản trị trong môi trường production của bạn. Ít nhất, bạn cần có một kế hoạch khôi phục cho từng trường hợp tê liệt mà bạn cho là chắc chắn sẽ xảy ra, chẳng hạn như lỗi phần cứng server hoặc xóa dữ liệu ngẫu nhiên. Ví dụ: một kế hoạch khôi phục rất cơ bản cho sự cố server có thể bao gồm danh sách các bước bạn đã thực hiện để triển khai server ban đầu, với các thủ tục bổ sung để khôi phục dữ liệu ứng dụng từ các bản backup . Kế hoạch khôi phục tốt hơn có thể, ngoài tài liệu tốt, tận dụng các tập lệnh triển khai và các công cụ quản lý cấu hình, chẳng hạn như Ansible, Chef hoặc Puppet, để giúp tự động hóa và nhanh chóng quá trình khôi phục.

Cần thiết cho production ? Đúng. Mặc dù kế hoạch khôi phục không tồn tại dưới dạng phần mềm trong môi trường server của bạn, nhưng chúng là thành phần cần thiết cho cài đặt production . Chúng cho phép bạn sử dụng các bản backup của bạn một cách hiệu quả và cung cấp kế hoạch chi tiết để xây dựng lại môi trường của bạn hoặc quay trở lại trạng thái mong muốn khi có nhu cầu.

Kế hoạch khôi phục mẫu

Sơ đồ trên là tổng quan về kế hoạch khôi phục cho một server database bị lỗi. Trong trường hợp này, server database sẽ được thay thế bằng một server mới có cùng phần mềm được cài đặt và bản backup tốt cuối cùng sẽ được sử dụng để khôi phục cấu hình và dữ liệu server . Cuối cùng, server ứng dụng sẽ được cấu hình để sử dụng server database mới.

Cân nhắc

  • Tài liệu Thủ tục: Tập hợp các tài liệu cần được tuân theo trong trường hợp hỏng hóc. Điểm khởi đầu tốt là xây dựng tài liệu từng bước mà bạn có thể làm theo để xây dựng lại server bị lỗi, sau đó thêm các bước để khôi phục dữ liệu ứng dụng và cấu hình khác nhau từ các bản backup
  • Công cụ tự động hóa: Tập lệnh và phần mềm quản lý cấu hình cung cấp tính năng tự động hóa, có thể cải thiện quy trình triển khai và khôi phục. Mặc dù hướng dẫn từng bước thường thích hợp để khôi phục đơn giản sau lỗi, nhưng chúng phải được thực hiện bởi một người và do đó không nhanh hoặc nhất quán như một quy trình tự động
  • Các thành phần quan trọng: Các thành phần cần thiết để ứng dụng của bạn hoạt động bình thường. Trong ví dụ trên, cả ứng dụng và server database đều là các thành phần quan trọng vì nếu không thành công, ứng dụng sẽ không khả dụng
  • Một điểm lỗi: Các thành phần quan trọng không có cơ chế chuyển đổi dự phòng tự động được coi là một điểm lỗi duy nhất. Bạn nên cố gắng loại bỏ các điểm thất bại đơn lẻ, với khả năng tốt nhất của bạn, để cải thiện tính khả dụng
  • Sửa đổi: Cập nhật tài liệu của bạn khi quá trình triển khai và khôi phục của bạn được cải thiện

3.Cân bằng tải

Cân bằng tải có thể được thêm vào môi trường server để cải thiện hiệu suất và tính khả dụng bằng cách phân phối dung lượng công việc trên nhiều server . Nếu một trong các server được cân bằng tải không thành công, các server khác sẽ xử lý lưu lượng đến cho đến khi server bị lỗi hoạt động trở lại. Trong môi trường server cloud , cân bằng tải thường có thể được thực hiện bằng cách thêm một server cân bằng tải, chạy phần mềm cân bằng tải ( reverse-proxy ), trước nhiều server chạy một thành phần cụ thể của ứng dụng.

Cần thiết cho production ? Không cần thiết. Cân bằng tải không phải lúc nào cũng bắt buộc đối với môi trường production nhưng nó có thể là một cách hiệu quả để giảm số lượng điểm lỗi đơn lẻ trong hệ thống, nếu được thực hiện đúng cách. Nó cũng có thể cải thiện hiệu suất bằng cách tăng thêm dung lượng thông qua mở rộng theo chiều ngang.

Cân bằng tải

Sơ đồ trên thêm một server ứng dụng bổ sung để chia sẻ tải và một bộ cân bằng tải để truyền tải các yêu cầu của user trên cả hai server ứng dụng. Cài đặt này có thể giúp tăng hiệu suất, nếu một server ứng dụng đang gặp khó khăn trong việc theo kịp lưu lượng truy cập và nó cũng có thể giúp giữ cho ứng dụng khả dụng nếu một trong các server ứng dụng bị lỗi. Tuy nhiên, nó vẫn có hai điểm lỗi duy nhất trong server database và server cân bằng tải.

Lưu ý: DigitalOcean Load Balancers là một dịch vụ cân bằng tải được quản lý đầy đủ, có tính khả dụng cao. Nếu bạn đang chạy ứng dụng của bạn trên DigitalOcean, dịch vụ Cân bằng tải có thể phù hợp với môi trường của bạn.

Cân nhắc

  • Các thành phần có thể cân bằng tải : Không phải tất cả các thành phần trong môi trường đều có thể được cân bằng tải một cách dễ dàng. Cần phải xem xét đặc biệt đối với một số loại phần mềm như database hoặc các ứng dụng trạng thái
  • Sao chép dữ liệu ứng dụng: Nếu server ứng dụng cân bằng tải lưu trữ local dữ liệu ứng dụng, chẳng hạn như các file được tải lên, thì dữ liệu này phải được cung cấp cho các server ứng dụng khác thông qua các phương pháp như sao chép hoặc hệ thống file chia sẻ. Điều này là cần thiết đảm bảo rằng dữ liệu ứng dụng sẽ khả dụng cho dù server ứng dụng nào được chọn để phục vụ yêu cầu của user
  • Tắc nghẽn hiệu suất: Nếu bộ cân bằng tải không có đủ tài nguyên hoặc không được cấu hình đúng cách, nó có thể làm giảm hiệu suất của ứng dụng của bạn
  • Các điểm lỗi duy nhất: Trong khi cân bằng tải được dùng để loại bỏ các điểm lỗi đơn lẻ, việc cân bằng tải có kế hoạch kém có thể thêm nhiều điểm lỗi đơn lẻ. Cân bằng tải được tăng cường với việc bao gồm một bộ cân bằng tải thứ hai với một IP tĩnh ở phía trước của cặp gửi lưu lượng truy cập đến một hoặc khác tùy thuộc vào tính khả dụng.

4. Giám sát

Giám sát có thể hỗ trợ môi trường server bằng cách theo dõi trạng thái của dịch vụ và xu hướng sử dụng tài nguyên server của bạn, do đó cung cấp khả năng hiển thị tuyệt vời vào môi trường của bạn.Một trong những lợi ích lớn nhất của hệ thống giám sát là chúng có thể được cấu hình để kích hoạt một hành động, chẳng hạn như chạy tập lệnh hoặc gửi thông báo, khi dịch vụ hoặc server gặp sự cố hoặc nếu một tài nguyên nhất định, chẳng hạn như CPU, bộ nhớ hoặc lưu trữ, trở nên sử dụng quá mức. Những thông báo này cho phép bạn phản ứng với sự cố nào ngay khi chúng xảy ra, điều này có thể giúp giảm thiểu hoặc ngăn chặn thời gian ngừng hoạt động của ứng dụng của bạn.

Cần thiết cho production ? Không nhất thiết, nhưng nhu cầu giám sát tăng lên khi môi trường production phát triển về quy mô và độ phức tạp. Nó cung cấp một cách dễ dàng để theo dõi các dịch vụ quan trọng và tài nguyên server của bạn. Đổi lại, giám sát có thể cải thiện khả năng phục hồi và thông báo cho việc lập kế hoạch và duy trì cài đặt của bạn.

Ví dụ giám sát

Sơ đồ trên là một ví dụ về hệ thống giám sát. Thông thường, server giám sát sẽ yêu cầu dữ liệu trạng thái từ phần mềm tác nhân đang chạy trên server ứng dụng và database , và mỗi tác nhân sẽ phản hồi với thông tin trạng thái phần mềm và phần cứng. Sau đó (các) administrator của hệ thống có thể sử dụng console giám sát để xem trạng thái tổng thể của ứng dụng và đi sâu vào thông tin chi tiết hơn, nếu cần.

Cân nhắc

  • Dịch vụ giám sát: Các dịch vụ và phần mềm mà bạn sẽ giám sát. Tối thiểu, bạn nên theo dõi trạng thái của tất cả các dịch vụ cần ở trạng thái hoạt động tốt để ứng dụng của bạn hoạt động bình thường
  • Tài nguyên để giám sát: Các tài nguyên mà bạn sẽ giám sát. Ví dụ về tài nguyên bao gồm sử dụng CPU, bộ nhớ, bộ nhớ, và mạng cũng như trạng thái của server nói chung
  • Lưu giữ dữ liệu: Khoảng thời gian mà bạn giữ lại dữ liệu giám sát trước khi loại bỏ nó. Điều này, cùng với sự lựa chọn của bạn về các mục để giám sát, sẽ ảnh hưởng đến dung lượng ổ đĩa mà hệ thống giám sát của bạn sẽ yêu cầu
  • Luật phát hiện sự cố: Các ngưỡng và luật xác định xem một dịch vụ hoặc tài nguyên có ở trạng thái OK hay không. Ví dụ: một dịch vụ hoặc server có thể được coi là tốt nếu nó đang chạy và phục vụ các yêu cầu, trong khi một tài nguyên, chẳng hạn như bộ nhớ, có thể kích hoạt cảnh báo nếu việc sử dụng nó đạt đến một ngưỡng nhất định trong một khoảng thời gian nhất định
  • Luật thông báo: Các ngưỡng và luật xác định xem có nên gửi thông báo hay không. Mặc dù thông báo là quan trọng, nhưng điều quan trọng không kém là điều chỉnh các luật thông báo của bạn để bạn không nhận được quá nhiều; một hộp thư đến chứa đầy cảnh báo và cảnh báo thường sẽ bị bỏ qua, khiến chúng gần như vô dụng như không có thông báo nào cả

5. Ghi log tập trung

Ghi log tập trung có thể hỗ trợ môi trường server bằng cách cung cấp một cách dễ dàng để xem và tìm kiếm log của bạn, log này thường được lưu trữ local trên các server riêng lẻ trên toàn bộ môi trường của bạn, ở một nơi duy nhất.Ngoài sự tiện lợi của việc không phải đăng nhập vào các server riêng lẻ để đọc log , ghi log tập trung cũng cho phép bạn dễ dàng xác định các vấn đề trải dài trên nhiều server bằng cách tương quan các log và số liệu của chúng trong một khung thời gian cụ thể. Nó cũng cho phép linh hoạt hơn về lưu giữ log vì log local có thể được tải từ server ứng dụng sang server log tập trung có bộ nhớ riêng, độc lập.

Cần thiết cho production ? Không, nhưng giống như giám sát, ghi log tập trung có thể cung cấp cái nhìn sâu sắc vô giá về môi trường server của bạn khi nó phát triển về quy mô và độ phức tạp. Ngoài việc thuận tiện hơn so với ghi log truyền thống, nó cho phép bạn nhanh chóng kiểm tra log server của bạn với khả năng hiển thị tốt hơn.

Ghi log tập trung

Sơ đồ trên là một ví dụ đơn giản về hệ thống ghi log tập trung. Một đại lý vận chuyển log được cài đặt trên mỗi server và được cấu hình để gửi log ứng dụng và database quan trọng đến server ghi log tập trung. Sau đó (các) administrator của hệ thống có thể xem, lọc và tìm kiếm tất cả các log quan trọng từ một console duy nhất.

Cân nhắc

  • Nhật ký để Thu thập: Các log cụ thể mà bạn sẽ gửi từ server của bạn đến server ghi log tập trung. Bạn nên thu thập các log quan trọng từ tất cả các server của bạn
  • Lưu giữ dữ liệu: Khoảng thời gian mà bạn lưu giữ log trước khi loại bỏ chúng. Điều này, cùng với sự lựa chọn log của bạn để thu thập, sẽ ảnh hưởng đến dung lượng ổ đĩa mà hệ thống ghi log tập trung của bạn sẽ yêu cầu
  • Bộ lọc log : Bộ lọc phân tích cú pháp log thuần túy thành dữ liệu log có cấu trúc. Lọc log sẽ cải thiện khả năng truy vấn, phân tích và vẽ biểu đồ dữ liệu theo những cách có ý nghĩa
  • Đồng hồ server : Đảm bảo rằng đồng hồ của các server của bạn được đồng bộ hóa và sử dụng được đặt thành cùng một múi giờ, để dòng thời gian log của bạn chính xác trên toàn bộ môi trường của bạn

Kết luận

Khi bạn đặt tất cả các thành phần lại với nhau, môi trường production của bạn có thể trông giống như sau:

Sản xuất

Đến đây bạn đã quen với các thành phần được dùng để hỗ trợ và cải thiện cài đặt server production , bạn nên xem xét cách bạn có thể tích hợp chúng với môi trường server của bạn . Tất nhiên, ta không đề cập đến mọi khả năng, nhưng điều này sẽ cung cấp cho bạn ý tưởng về nơi bắt đầu. Hãy nhớ thiết kế và triển khai môi trường server của bạn dựa trên sự cân bằng giữa các nguồn lực sẵn có và mục tiêu production của bạn .

Nếu bạn quan tâm đến việc cài đặt một môi trường như ở trên, hãy xem hướng dẫn này: Xây dựng cho Sản xuất: Ứng dụng Web .

Tags:

Các tin liên quan

Cách triển khai ứng dụng web Ruby dựa trên Sinatra trên Ubuntu 13
2014-02-20
Cách cấu hình web server theo cụm với Varnish và Nginx trên Ubuntu 13.10
2014-01-24
Cách triển khai các ứng dụng web Flask bằng uWSGI Behind Nginx trên CentOS 6.4
2014-01-14
Cách triển khai ứng dụng web CherryPy đằng sau Nginx Reverse-Proxy
2014-01-14
Cách tạo ứng dụng web với HMVC PHP5 Framework Kohana
2013-12-30
Hướng dẫn đơn giản về cách cài đặt ứng dụng trực diện web trên VPS
2013-12-09
So sánh web server (Rack) cho Ứng dụng Web Ruby
2013-11-25
So sánh các web server cho các ứng dụng web dựa trên Python
2013-10-28
Cách sử dụng node.js, request và cheerio để thiết lập Web-Scraping đơn giản
2013-09-16
Cách tạo một ứng dụng web nhỏ với CakePHP trên VPS (Phần 1)
2013-08-23