Tại sao không nên có cơ sở dữ liệu và máy chủ web trên cùng một máy?

Lắng nghe cuộc phỏng vấn của Scott Hanselman với nhóm Stack Overflow ( phần 1 và 2 ), anh ta kiên quyết rằng máy chủ SQL và máy chủ ứng dụng nên ở trên các máy riêng biệt. Đây có phải chỉ để đảm bảo rằng nếu một máy chủ bị xâm nhập, cả hai hệ thống đều không truy cập được? Các vấn đề bảo mật có vượt quá sự phức tạp của hai máy chủ (chi phí thêm, kết nối mạng chuyên dụng giữa hai máy, bảo trì nhiều hơn, v.v.), đặc biệt đối với một ứng dụng nhỏ, trong đó không có phần nào sử dụng quá nhiều CPU hoặc bộ nhớ? Ngay cả với hai máy chủ, với một máy chủ bị xâm nhập, kẻ tấn công vẫn có thể gây thiệt hại nghiêm trọng, bằng cách xóa cơ sở dữ liệu hoặc làm rối mã ứng dụng.

Tại sao điều này sẽ là một vấn đề lớn như vậy nếu hiệu suất không phải là một vấn đề?

1. Bảo vệ. Máy chủ web của bạn sống trong DMZ, có thể truy cập internet công cộng và lấy dữ liệu đầu vào không đáng tin cậy từ người dùng ẩn danh. Nếu máy chủ web của bạn bị xâm phạm và bạn đã tuân theo các quy tắc đặc quyền tối thiểu trong việc kết nối với DB của mình, mức độ hiển thị tối đa là những gì ứng dụng của bạn có thể thực hiện thông qua API cơ sở dữ liệu. Nếu bạn có một tầng kinh doanh ở giữa, bạn có thêm một bước giữa kẻ tấn công và dữ liệu của bạn. Mặt khác, nếu cơ sở dữ liệu của bạn nằm trên cùng một máy chủ, thì kẻ tấn công hiện có quyền truy cập root vào dữ liệu và máy chủ của bạn.
2. Khả năng mở rộng. Giữ máy chủ web của bạn không trạng thái cho phép bạn mở rộng quy mô máy chủ web của mình theo chiều ngang khá dễ dàng. Nó rất khó khăn để theo chiều ngang rộng một máy chủ cơ sở dữ liệu.
3. Hiệu suất. 2 hộp = 2 lần CPU, 2 lần RAM và 2 lần trục chính để truy cập đĩa.

Tất cả những gì đang được nói, tôi chắc chắn có thể thấy các trường hợp hợp lý mà không có điểm nào thực sự quan trọng.

Nó không thực sự trọng (bạn hoàn toàn có thể vui vẻ chạy trang web của mình với web / cơ sở dữ liệu trên cùng một máy), đó chỉ là bước dễ nhất để nhân rộng ..

Đó chính xác là những gì StackOverflow đã làm - bắt đầu với một máy duy nhất chạy IIS / SQL Server, sau đó khi nó bắt đầu được tải nặng, một máy chủ thứ hai đã được mua và máy chủ SQL được chuyển sang đó.

Nếu hiệu suất không phải là vấn đề, đừng lãng phí tiền mua / bảo trì hai máy chủ.

Mặt khác, đề cập đến một blog Scott khác (Watermasyck, của Tellect) - họ thấy rằng hầu hết người dùng có thể tăng tốc các trang web (sử dụng Máy chủ cộng đồng của Tellect), bằng cách đặt cơ sở dữ liệu trên cùng một máy như trang web. Tuy nhiên, trong trường hợp khách hàng của họ, thông thường máy chủ db & web là ứng dụng duy nhất trên máy đó và trang web không gây căng thẳng cho máy nhiều như vậy. Sau đó, hiệu quả của việc không phải gửi dữ liệu qua mạng nhiều hơn tạo nên sự căng thẳng gia tăng.

Tôi sẽ nghĩ rằng yếu tố lớn sẽ là hiệu suất. Cả máy chủ web / mã ứng dụng và SQL Server sẽ lưu trữ dữ liệu thường được yêu cầu trong bộ nhớ và bạn đang giết chết hiệu suất bộ đệm của mình bằng cách chạy chúng trong cùng một không gian bộ nhớ.

Tom là chính xác về điều này. Một số lý do khác là nó không hiệu quả về chi phí và có thêm rủi ro bảo mật.

Máy chủ web có các yêu cầu phần cứng khác với máy chủ cơ sở dữ liệu. Máy chủ cơ sở dữ liệu tốt hơn với nhiều bộ nhớ và mảng đĩa thực sự nhanh trong khi máy chủ web chỉ yêu cầu đủ bộ nhớ để lưu trữ tệp và yêu cầu DB thường xuyên (tùy thuộc vào thiết lập của bạn). Về hiệu quả chi phí, hai máy chủ sẽ không nhất thiết phải rẻ hơn, tuy nhiên tỷ lệ hiệu suất / chi phí sẽ cao hơn do bạn không phải sử dụng các ứng dụng khác nhau cạnh tranh tài nguyên. Vì lý do này, có lẽ bạn sẽ phải chi nhiều hơn cho một máy chủ phục vụ cả hai và cung cấp hiệu suất tương đương với 2 máy chủ chuyên dụng.

Mối quan tâm bảo mật là nếu máy đơn bị xâm phạm, cả máy chủ web và cơ sở dữ liệu đều dễ bị tấn công. Với hai máy chủ, bạn có một số phòng thở vì máy chủ thứ 2 sẽ vẫn an toàn (ít nhất là trong một thời gian).

Ngoài ra, có một số lợi ích về khả năng mở rộng vì bạn chỉ có thể phải duy trì một vài máy chủ cơ sở dữ liệu được sử dụng bởi một loạt các ứng dụng web khác nhau. Bằng cách này, bạn có ít công việc hơn để áp dụng nâng cấp hoặc vá lỗi và thực hiện điều chỉnh hiệu suất. Tôi tin rằng có các công cụ quản lý máy chủ để thực hiện các tác vụ này dễ dàng hơn (trong trường hợp máy đơn lẻ).

An ninh là một mối quan tâm chính. Lý tưởng nhất là máy chủ cơ sở dữ liệu của bạn nên ngồi sau một tường lửa chỉ có các cổng cần thiết để thực hiện truy cập dữ liệu được mở. Ứng dụng web của bạn phải được kết nối với máy chủ cơ sở dữ liệu bằng tài khoản SQL có đủ quyền để ứng dụng hoạt động và không còn nữa. Ví dụ: bạn nên xóa các quyền cho phép thả các đối tượng và chắc chắn bạn không nên kết nối bằng các tài khoản như 'sa'.

Trong trường hợp bạn mất máy chủ web vào một vụ không tặc (nghĩa là sự leo thang đặc quyền toàn diện đối với quyền quản trị viên), trường hợp xấu nhất là cơ sở dữ liệu của ứng dụng của bạn có thể bị xâm phạm nhưng không phải là toàn bộ máy chủ cơ sở dữ liệu (như trường hợp máy chủ cơ sở dữ liệu và máy chủ web là cùng một máy). Nếu bạn đã mã hóa chuỗi kết nối cơ sở dữ liệu của mình và tin tặc không đủ hiểu biết để giải mã chúng thì tất cả những gì bạn mất là máy chủ web.

Một yếu tố chưa được đề cập đến là cân bằng tải. Nếu bạn bắt đầu nghĩ máy chủ web và cơ sở dữ liệu là các máy riêng biệt, bạn sẽ tối ưu hóa cho các chuyến đi vòng mạng ít hơn và cũng dễ dàng hơn để thêm máy chủ web thứ hai hoặc công cụ cơ sở dữ liệu thứ hai khi nhu cầu tăng.

Tôi có thể nói từ kinh nghiệm đầu tay rằng việc đặt máy chủ web và cơ sở dữ liệu trên các máy khác nhau thường là một ý tưởng hay. Nếu bạn có một ứng dụng sử dụng nhiều tài nguyên, nó có thể dễ dàng khiến chu kỳ CPU trên máy đạt đến đỉnh điểm, về cơ bản khiến máy ngừng hoạt động. Tuy nhiên, nếu ứng dụng của bạn hạn chế sử dụng cơ sở dữ liệu, có lẽ sẽ không có vấn đề gì lớn khi họ chia sẻ máy chủ.

Ồ, không ai đưa ra sự thật rằng nếu bạn thực sự mua máy chủ SQL với giá 5 nghìn đô la, bạn có thể muốn sử dụng nó nhiều hơn ứng dụng web của mình. Nếu bạn sử dụng express, có thể bạn không quan tâm. Tôi thấy các máy chủ SQL chạy Cơ sở dữ liệu cho 20 đến 30 ứng dụng, vì vậy việc đưa nó lên máy chủ web sẽ không thông minh.

Thứ hai, phụ thuộc vào người mà máy chủ dành cho. Tôi làm việc cho các công ty tài chính và chính phủ. Vì vậy, chúng tôi sử dụng một cơn đau điên rồ trong cách tiếp cận ass chỉ sử dụng sprocs và giới hạn các cổng từ máy chủ web sang SQL. Vì vậy, nếu ứng dụng web bị hack. Điều duy nhất mà hacker có thể làm là gọi sprocs vì tài khoản người dùng trên máy chủ web bị khóa để chỉ nhìn thấy / gọi sprocs trên DB. Vì vậy, bây giờ tin tặc phải tìm ra cách vào DB. Nếu nó trên máy chủ web thì loại đó dễ dàng để truy cập.

Tôi đồng ý với Daniel Earwicker - câu hỏi bảo mật còn khá nhiều thiếu sót.

Nếu bạn có một thiết lập hộp duy nhất với máy chủ web và chỉ có cơ sở dữ liệu cho máy chủ web đó, nếu máy chủ web đó bị xâm phạm, bạn sẽ mất cả máy chủ web và chỉ cơ sở dữ liệu cho ứng dụng cụ thể đó.

Điều này giống hệt như những gì xảy ra nếu bạn mất máy chủ web khi thiết lập 2 máy chủ. Bạn mất máy chủ web và chỉ cơ sở dữ liệu cho ứng dụng cụ thể đó.

Đối số 'phần còn lại của tính toàn vẹn của máy chủ DB được duy trì' trong đó bạn có thiết lập 2 máy chủ là không liên quan, bởi vì trong kịch bản đầu tiên, mọi máy chủ cơ sở dữ liệu khác liên quan đến mọi ứng dụng khác (nếu có) cũng không bị ảnh hưởng - như, như họ, được lưu trữ ở nơi khác.

Tương tự như vậy, với câu hỏi được đặt ra bởi Kev 'còn tất cả các cơ sở dữ liệu khác nằm trên máy chủ DB thì sao? Tất cả những gì bạn đã mất là một cơ sở dữ liệu. '

• nếu bạn đang lưu trữ một ứng dụng và cơ sở dữ liệu trên một máy chủ, bạn sẽ chỉ lưu trữ cơ sở dữ liệu trên máy chủ đó có liên quan đến ứng dụng đó. Do đó, bạn sẽ không mất bất kỳ cơ sở dữ liệu bổ sung nào trong một thiết lập máy chủ khi so sánh với thiết lập nhiều máy chủ.

Ngược lại, trong thiết lập 2 máy chủ, nơi kẻ tấn công có quyền truy cập vào Máy chủ Web và bằng proxy, quyền hạn chế (trong trường hợp tốt nhất) cho máy chủ cơ sở dữ liệu, họ có thể gặp rủi ro cho cơ sở dữ liệu của mọi ứng dụng khác bằng cách mang theo truy vấn chậm, chiếm nhiều bộ nhớ hoặc tối đa hóa không gian lưu trữ có sẵn trên máy chủ cơ sở dữ liệu. Bằng cách tách các ứng dụng ra khỏi mối quan tâm riêng của chúng, rất giống như ảo hóa, bạn cũng cách ly chúng cho mục đích bảo mật theo cách tích cực.

Nó phụ thuộc vào ứng dụng và mục đích. Khi tính sẵn sàng và hiệu suất cao không quan trọng, sẽ không tệ khi không tách DB và máy chủ web. Đặc biệt là xem xét mức tăng hiệu suất - nếu ứng dụng tạo ra một lượng lớn truy vấn cơ sở dữ liệu, một lượng tải mạng đáng kể có thể được loại bỏ bằng cách giữ tất cả trên cùng một hệ thống, giữ cho thời gian phản hồi thấp.

Tôi nghĩ rằng bởi vì hai máy thường sẽ cần phải được tối ưu hóa theo những cách khác nhau. Ngoài ra, tôi không biết, chúng tôi chạy tất cả các ứng dụng của mình với cơ sở dữ liệu máy chủ trên cùng một máy - được cho là chúng tôi không phải đối mặt công khai - nhưng chúng tôi không gặp vấn đề gì.

Tôi không thể tưởng tượng rằng có quá nhiều người quan tâm đến việc một máy bị xâm phạm cả hai vì ứng dụng web thường sẽ có quyền truy cập gần như không bị hạn chế đối với ít nhất là dữ liệu nếu không phải là lược đồ bên trong cơ sở dữ liệu.

Quan tâm đến những gì người khác có thể nói.

Tôi đã nghe podcast đó, và nó thật thú vị, nhưng đối số bảo mật không có ý nghĩa gì với tôi. Nếu bạn đã xâm phạm máy chủ A và máy chủ đó có thể truy cập dữ liệu trên máy chủ B, thì ngay lập tức bạn có quyền truy cập vào dữ liệu trên máy chủ B.

Giấy phép cơ sở dữ liệu không phải là cheep và thường được tính cho mỗi CPU, do đó bằng cách tách ra các máy chủ web của bạn, bạn có thể giảm chi phí cho giấy phép cơ sở dữ liệu của mình.

Ví dụ: nếu bạn có 1 máy chủ làm cả web và cơ sở dữ liệu chứa 8 CPU, bạn sẽ phải trả tiền cho một giấy phép 8 cpu. Tuy nhiên, nếu bạn có hai máy chủ, mỗi máy chủ có 4 CPU và chạy cơ sở dữ liệu trên một máy chủ, bạn sẽ chỉ phải trả tiền cho 4 giấy phép cpu

Một mối quan tâm khác là các cơ sở dữ liệu muốn chiếm hết bộ nhớ khả dụng và giữ nó để dự trữ khi nó muốn sử dụng nó. Bạn có thể buộc nó giới hạn bộ nhớ nhưng điều này có thể làm chậm đáng kể việc truy cập dữ liệu.

Lập luận rằng có một hiệu suất thực sự cần có bằng cách chạy một máy chủ cơ sở dữ liệu trên máy chủ web là một đối số thiếu sót.

Do các máy chủ cơ sở dữ liệu lấy chuỗi truy vấn và trả về tập kết quả, dữ liệu thực sự chảy từ máy chủ dữ liệu sang máy chủ web là tương đối nhỏ, nhưng mã lực cần thiết để xử lý truy vấn và tạo tập kết quả là tương đối lớn. Tối ưu hóa hiệu suất xung quanh thời gian truyền dữ liệu do đó tối ưu hóa xung quanh điều sai.

Về bảo mật, có những lợi thế khi có máy chủ dữ liệu trên một hộp khác với máy chủ web. Có một thiết lập như vậy không phải là tất cả và kết thúc tất cả bảo mật, nhưng đó là một bước đi đúng hướng.

Về khả năng mở rộng, việc thêm các máy chủ web và đặt chúng vào cụm để xử lý lưu lượng truy cập tăng lên rất dễ dàng và tương đối rẻ. Thật không dễ dàng và rẻ tiền để thêm các máy chủ dữ liệu và phân cụm chúng. Ngoài ra, máy chủ web và máy chủ dữ liệu có nhu cầu phần cứng khác nhau, vì vậy nhiều hộp giúp mở rộng khả năng mở rộng.

Nếu bạn đang bắt đầu nhỏ và chỉ có một hộp, thì một cách tốt sẽ là sử dụng máy ảo. Chạy máy chủ web và máy chủ dữ liệu trong các máy ảo khác nhau trên một máy chủ cung cấp cho bạn tất cả lợi ích của các hộp riêng biệt với giá của một hộp giá lớn.

Hệ điều hành là một xem xét khác. Mặc dù cơ sở dữ liệu của bạn có thể yêu cầu không gian bộ nhớ lớn hơn và do đó UNIX, máy chủ web của bạn - hay cụ thể hơn là máy chủ ứng dụng của bạn vì bạn chỉ đề cập đến hai tầng - có thể là dựa trên .Net và do đó yêu cầu Windows.

Đồng ý! Đây là điều an toàn hơn khi cài đặt Máy chủ DB của bạn trên Máy khác và Ứng dụng của bạn trên Máy chủ Web. Sau đó, bạn kết nối ứng dụng của mình với DB bằng Liên kết web. Cảm ơn nó