Liệu ảo hóa một máy chủ có nghĩa là một lớp HĐH khác để vá và cập nhật, nhiều công việc hơn và rủi ro lớn hơn?


27

Tôi đã thực hiện tìm kiếm và không tìm thấy bất cứ điều gì giải quyết các vấn đề liên quan đến vá lỗi và cập nhật hệ thống. Tôi đã có hướng dẫn nói rằng các máy chủ cần phải có các bản vá cần thiết. Nếu tôi có một máy chủ VM thì đó có phải là một lớp bổ sung để vá và cập nhật - ngay cả với các trình ảo hóa kim loại trần? Trái ngược với việc có một máy chủ kim loại? (tức là nhiều công việc hơn và thử nghiệm và tài liệu theo hướng dẫn của tôi).

Làm thế nào thường xuyên làm siêu thị loại 1 / kim loại trần được cập nhật? Có vấn đề gì không? Có phải thực tế rằng nó là một lớp phần mềm bổ sung giới thiệu sự phức tạp và rủi ro hơn (bảo mật và độ tin cậy)? (ví dụ: phần mềm không có lỗi 99% x phần mềm không có lỗi 99% = hệ thống không có lỗi 98%)?

(Trải nghiệm thực tế của tôi là với VMWare Workstation và Server và VirtualBox.)


Điều này có trả lời câu hỏi của bạn không?
ewwhite

Tôi nghĩ rằng nó trả lời một nửa của nó ....
127379

Câu trả lời:


20

Có, đôi khi các sản phẩm như VMware phải được vá ( các bản cập nhật được tích lũy ), nhưng các bản vá đến ít thường xuyên hơn so với hệ điều hành chính và vectơ tấn công tiềm năng nhỏ hơn - không thể truy cập công khai .

Tôi sẽ sử dụng VMware ESXi phiên bản 5.0 (không phải 5.1) làm ví dụ ...

ESXi 5.0 đã có lịch cập nhật sau:

Từ tháng 9/2011 đến nay, đã có bản cập nhật TEN cho sản phẩm ESXi 5.0. Trong số đó, SIX là các bản cập nhật tập trung vào bảo mật được đưa vào các gói cập nhật với các mô tả như:

" Lỗ hổng phân tích lưu lượng truy cập ESXi NFS" - CVE-2012-2448 .

Những lỗ hổng bảo mật này là có thật, vì đôi khi chúng phản ánh các lỗi bảo mật chung của Linux, nhưng tôi nghĩ rằng hầu hết các tổ chức không dễ bị rủi ro. Tuy nhiên, tùy thuộc vào kỹ sư để đánh giá rủi ro này. Người dùng của bạn muốn thời gian chết lớn để khắc phục khai thác sau đây ?

"Macro encode_name trong misc / mntent_r.c trong Thư viện GNU C (còn gọi là glibc hoặc libc6) 2.11.1 trở về trước, như được sử dụng bởi ncpmount và mount.cifs, không xử lý đúng các ký tự dòng mới trong tên mountpoint, cho phép người dùng cục bộ để từ chối dịch vụ (tham nhũng mtab) hoặc có thể sửa đổi các tùy chọn gắn kết và nhận các đặc quyền, thông qua yêu cầu gắn kết được chế tạo. "

Có lẽ? Có thể không.

Tôi chạy Trình quản lý cập nhật của VMware , nhưng chỉ có xu hướng cập nhật nếu tôi bị ảnh hưởng bởi lỗi hoặc yêu cầu cải tiến tính năng. Khi chạy trong một thiết lập cụm, việc vá lỗi rất dễ dàng mà không có thời gian chết đối với máy ảo đang chạy. Nếu không có lý do cấp bách nào khác, tôi sẽ cố gắng cập nhật hàng quý. Các máy chủ riêng lẻ sẽ yêu cầu khởi động lại đầy đủ, vì các bản vá được phân phối dưới dạng hình ảnh nguyên khối.

Một lưu ý phụ, bất cứ khi nào tôi kế thừa thiết lập VMware ESXi hoặc hoạt động trên hệ thống mà tôi không thường quản lý, tôi thường thấy các máy chủ đang chạy chưa bao giờ có bất kỳ bản vá VMware nào được áp dụng. Điều đó là sai !! Nhưng tôi có thể thấy các quản trị viên có thể mắc lỗi như thế nào khi hệ thống hoạt động.


1
Thêm vào đó là cơ sở hạ tầng VmWare bình thường nên có dung lượng dự phòng - vì vậy bạn có thể di chuyển vm đến các máy chủ và bản vá khác. Nhiều công việc hơn - có (MS iirc có thể làm điều đó tự động) nhưng không có nhiều thời gian chết hơn.
TomTom

thậm chí tốt hơn là khi không ai từng cập nhật chương trình cơ sở hoặc trình điều khiển
SpacemanSpiff

Vì vậy, bạn đang nói: 1. Vâng, công việc vá và cập nhật, ghi chép và kiểm tra máy chủ kim loại nhiều hơn (tuy nhiên thời gian chết ít hơn vì bạn có thể "di chuyển" và "lật" máy chủ VM). 2. Các siêu giám sát kim loại trần nhận / cần cập nhật ít thường xuyên hơn các hệ điều hành chính. Ví dụ ESXi 5.0 với 10 bản cập nhật trong 5 tháng. Tuy nhiên, sẽ có một bản sao của một số lỗi Linux cho các trình ảo hóa dựa trên Linux.
127379

6

Đây là một câu hỏi khá hay nếu bạn chưa quen với ảo hóa với các máy chủ 'kim loại trần'. Làm mọi thứ theo cách này đòi hỏi một tư duy khác với cách tiếp cận mà bạn có thể thực hiện với các trình ảo hóa chạy như một dịch vụ / ứng dụng trên hệ điều hành thông thường.

Theo kinh nghiệm của tôi, có lẽ công bằng khi nói rằng ESX và HyperV cần ít bản vá tổng thể hơn các hệ điều hành thông thường. Điều này không có nghĩa là họ hoàn toàn không cần vá, hoặc áp dụng một số bản vá sẽ không có lợi bất kể "nhu cầu", nhưng điều này có nghĩa là việc can thiệp vào các dịch vụ của bạn để vá máy chủ sẽ ít thường xuyên hơn và nhiều hơn dưới sự kiểm soát của bạn. Có nguy cơ bảo mật tiềm ẩn đối với các hệ điều hành của trình ảo hóa giống như các hệ điều hành khác, và trong khi bạn có thể giảm thiểu rủi ro này (ví dụ: chỉ phơi bày quản lý trình ảo hóa trên Vlan bị cô lập mà không thể truy cập một cách hợp lý từ máy chủ bị xâm nhập) Sẽ thật ngu ngốc khi giả vờ không có rủi ro nào cả.

Vì vậy, nếu bạn có 4 máy chủ không ảo, và bạn chuyển tất cả chúng sang cùng một máy chủ ảo hóa, thì có, bạn đang tăng số lượng gián đoạn có thể do cần phải vá hệ thống máy chủ (hoặc xử lý một vấn đề phần cứng, vv, cho vấn đề đó).

Trong khi tôi muốn đề nghị các cơ hội occuring nguy cơ này là tương đối thấp (Tôi đang nói về sự khác biệt giữa vá một máy chủ ảo và các loại vá mà yêu cầu khởi động lại mà bạn sẽ phải làm gì để một hệ thống độc lập nào ), không thể tránh khỏi thực tế là tác động cao.

Vậy tại sao chúng ta làm điều đó sau đó?

Lợi ích thực sự của ảo hóa đến từ việc có thể thiết lập nhiều hơn một máy chủ và cấu hình các máy chủ để hoạt động cùng nhau, cho phép khách được chuyển từ máy chủ này sang máy chủ khác trong trường hợp một máy chủ bị lỗi hoặc bạn muốn lên lịch vá các hệ thống máy chủ.

Sử dụng phương pháp này, tôi đã lần lượt quản lý để vá 5 máy chủ ESX mà không có sự gián đoạn nào đối với 40 máy chủ ảo đang chạy trên đầu chúng. Đây đơn giản chỉ là vấn đề kinh tế theo quy mô - một khi bạn có đủ máy khách ảo tiềm năng để tạo ra giá trị để xây dựng loại thiết lập phức tạp này và quản lý nó bằng loại công cụ @ewwhite đề cập trong câu trả lời của mình, việc hoàn vốn giảm rủi ro bạn lo lắng về việc đến rất nhanh.


4

Một máy chủ ảo sẽ yêu cầu bảo trì tương tự và vá các máy chủ vật lý, các trình ảo hóa kim loại trần sẽ yêu cầu cập nhật, để bảo mật, nhưng cũng để sửa lỗi và cải thiện hiệu suất. Bạn càng có nhiều máy chủ, bạn sẽ phải làm nhiều việc hơn để cập nhật chúng, điều đó không quan trọng nếu chúng là vật lý hay ảo.


0

Dựa trên các câu trả lời trên có vẻ như: Ảo hóa một máy chủ đã gây ra sự phức tạp và rủi ro hơn về bảo mật và độ tin cậy, nhưng những điều này cần được cân nhắc với lợi ích của việc có thể giảm thời gian chết bằng cách ảo hóa máy chủ.

Nếu môi trường của bạn yêu cầu kiểm toán, kiểm tra và tài liệu, lợi ích chi phí của khối lượng công việc tăng thêm của môi trường ảo hóa, sẽ phải được tính đến với số lượng máy chủ và nhân viên hệ thống mà bạn có. Trong môi trường của chúng tôi, chúng tôi không có thời gian của nhân viên / nhân viên để duy trì lộ trình kiểm toán cho một môi trường ảo hóa. Trong quy trình kinh doanh của chúng tôi, chúng tôi có thể mất một số thời gian chết, nhưng chúng tôi không thể thiếu một bản kiểm toán và tài liệu.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.