Di chuyển máy chủ trong cùng tòa nhà

Đây là kịch bản của tôi: Tôi là một nhà phát triển kế thừa (không biết đến tôi) ba máy chủ đặt trong văn phòng của tôi. Tôi cũng được thừa hưởng công việc là quản trị viên của các máy chủ với sự thiếu kiến ​​thức quản trị máy chủ và google / ServerFault làm điểm tham chiếu. May mắn thay, tôi thực sự chưa bao giờ phải tiếp xúc thực tế với máy móc hoặc giải quyết bất kỳ vấn đề nào vì chúng luôn 'chỉ hoạt động'.

Tất cả ba máy được đặt trong cùng một phòng dữ liệu và phục vụ mục đích sau:

Machine1- IIS 8.0 lưu trữ một số ứng dụng nội bộ
Machine2- Lưu trữ dữ liệu SQL Server 2008 R2 cho các ứng dụng nội bộ
Machine3- Kho lưu trữ nhân bản SQL Server 2008 R2 củaMachine2

Cả ba đều có ổ cứng gắn ngoài được kết nối thường xuyên sao lưu.

Tôi đã được thông báo rằng cả ba cần phải chuyển từ phòng dữ liệu này sang phòng khác trong cùng một cơ sở. Tôi sẽ không hoàn thành việc di chuyển vật lý của phần cứng, điều đó sẽ được xử lý bởi một người điều hành có thẩm quyền.

Ngoài việc hoàn thành một bản sao lưu đầy đủ của mỗi cái, tôi cần cân nhắc những gì trước khi đưa ra giả thuyết về việc bật công tắc điện và xem thế giới của tôi chuyển động?

^{Tôi biết rằng thật xa lý tưởng khi cả ba người nằm trong cùng một phòng / cơ sở nhưng điều đó vượt quá phạm vi của câu hỏi này.}

Câu hỏi thực sự thú vị, cũng được hỏi :)

Có một vài điều bạn cần kiểm tra trước động thái này, một số dễ, một số khó.

Nguồn - kiểm tra xem phòng mới không chỉ có đúng ổ cắm điện mà còn đúng loại - như ở loại đầu nối vật lý và nếu vị trí hiện tại cho phép các pha điện khác nhau trên mỗi máy chủ để bảo vệ chống lại sự cố một pha thì tôi Chúng tôi rất mong bạn nhân rộng điều đó ở vị trí mới.

Làm mát - bạn cần kiểm tra xem sẽ không có sự tích tụ nhiệt ngay lập tức hoặc từ từ sẽ dẫn đến quá nhiệt và tắt máy chủ tiềm năng. Bạn thường có thể tra cứu công suất tối đa (tính bằng watt) hoặc nhiệt (tính bằng BTU) mà mỗi máy chủ có thể rút ra từ trang web của nhà sản xuất - hãy cho người quản lý tòa nhà của bạn biết điều này và nhận được xác nhận bằng văn bản từ họ nói rằng việc làm mát ở vị trí đó sẽ đối phó .

Kết nối mạng - đây là một điều khó khăn - không chỉ có cùng số lượng cổng cần được sao chép giữa vị trí cũ và mới mà cả kiểu, tốc độ và quan trọng nhất là cấu hình của chúng. Điểm cuối cùng này là chìa khóa - đã có lúc gần như tất cả các cổng trong mạng gần như bằng nhau - Tôi đủ tuổi để nhớ những lần đó! nhưng ngày nay, số lượng cấu hình cổng và vị trí trong mạng mà bất kỳ một cổng nào cũng có thể là thiên văn, bạn cần đảm bảo rằng mọi người trong mạng của bạn sao chép MỌI THỨ để giống hệt nhau từ cũ sang mới - một lần nữa hãy viết điều này bằng văn bản không dễ Nếu có vấn đề xảy ra với động thái này, tôi sẽ đặt tiền vào các cổng mạng không giống nhau, điều đó xảy ra mọi lúc.

'Các kết nối khác' - bạn có biết máy chủ của mình có kết nối nào khác ngoài nguồn và mạng không? có lẽ họ có các liên kết Kênh sợi tới bộ nhớ chia sẻ, liên kết KVM đến màn hình quản lý dùng chung - một lần nữa nếu họ cần sao chép chúng giống hệt nhau.

Khác với điều đó cảm thấy tự do để trở lại đây với bất kỳ câu hỏi cụ thể hơn, và tôi hy vọng di chuyển diễn ra tốt đẹp.

Các câu trả lời khác bao gồm các khía cạnh kỹ thuật của việc di chuyển. Bạn cũng có thể phải xem xét một số điều khác.

Đảm bảo người dùng biết rằng các ứng dụng của họ sẽ bị hỏng trong quá trình di chuyển. Bạn sẽ muốn lên lịch di chuyển, có lẽ trong giờ không làm việc, để bạn giảm thiểu số lượng người bị ảnh hưởng.

Có một người có kiến ​​thức (hoặc người) kiểm tra các ứng dụng sau khi bạn đưa lên các máy chủ. Yêu cầu họ kiểm tra độ tỉnh táo để đảm bảo các ứng dụng hoạt động như mong đợi.

Sau khi thử nghiệm, hãy cho người dùng của bạn biết rằng việc di chuyển đã kết thúc và yêu cầu họ cho bạn biết nếu họ có bất kỳ vấn đề nào.

Thật khó để nói và giới hạn "quá rộng" cho định dạng của chúng tôi. Điều quan trọng nhất bạn cần kiểm tra là nếu bạn cần cấu hình lại mạng của mình theo bất kỳ cách nào nếu chúng có thể tiếp tục chạy với cùng một địa chỉ. Ngay cả khi họ có thể giữ cùng một địa chỉ, hãy đảm bảo rằng chúng không được định cấu hình qua DHCP và / hoặc xác minh máy chủ DHCP sẽ khả dụng tại vị trí mới.

Lưu ý bên lề: Như bạn đã nói, có máy chủ SQL và máy nhân bản không còn lý tưởng. Tuy nhiên, có các ổ đĩa sao lưu ở cùng một vị trí thực sự nguy hiểm. Bạn cần phải có bản sao lưu của bạn ở một vị trí vật lý khác.

Các câu trả lời khác có cân nhắc trước khi di chuyển tốt. Tuy nhiên, bạn cũng nên lập kế hoạch về cách bạn tổ chức di chuyển thực tế. Từ thực tế rằng Machine3 là một tấm gương của Machine2 , có vẻ như thời gian hoạt động là một sự cân nhắc đáng kể cho (các) cơ sở dữ liệu SQL Server 2008 R2. Thực tế đó là một tấm gương cung cấp cho bạn một cơ hội. Lý do cho sự tồn tại của một chiếc gương là có sẵn khi máy chủ chính không có. Điều đó bao gồm không có sẵn do bảo trì, bao gồm di chuyển.

Lập một kế hoạch:
Bạn nên lập một kế hoạch bằng văn bản cho việc di chuyển sẽ được thực hiện như thế nào. Bạn có thể cần phải có khả năng cung cấp kế hoạch này, hoặc một phần của kế hoạch đó, cho mọi người xử lý các phần của công việc (ví dụ: máy động lực). Kế hoạch này nên bao gồm tất cả các hoạt động trước khi di chuyển, di chuyển thực tế và hành động sau di chuyển (ví dụ: xác minh chức năng).

Di chuyển cơ bản:

1. Move Machine3 (máy chủ SQL): Hoạt động đầy đủ. Xác minh đồng bộ lại.
2. Move Machine2 : Giúp nó hoạt động đầy đủ.
3. Move Machine1 : Giúp nó hoạt động đầy đủ.

Mô tả chi tiết hơn về việc di chuyển:

Sau đây bao gồm hai phương thức (Đường dẫn A và B) sử dụng Machine3 để kiểm tra các kết nối cho Machine1 và / hoặc Machine2 . Bạn chỉ nên sử dụng một phương pháp. Cách nào để làm như vậy, hoặc thậm chí nếu sử dụng, tùy thuộc vào thông tin không có trong câu hỏi (ví dụ: tách vật lý của các vị trí máy cuối cùng, kích thước vật lý của máy, độ dài của dây mạng / nguồn, khả năng mở rộng cho cùng, sự giống nhau của cấu hình cổng mạng, nhu cầu thời gian hoạt động, v.v.). Sử dụng Machine3 để kiểm tra các kết nối này có khả năng cho phép thời gian hoạt động cao hơn cho Machine2 , nhưng đặc biệt đối với Machine1 , không có gương. Bạn có thể chọn sử dụng một trong hai phương pháp hoặc không.

1. Di chuyển máy3 trước.

   • Để lại Machine1 và Machine2 tại chỗ.
   • Sao lưu máy3 , sau đó tắt máy
   • Nhận Machine3 hoàn toàn di chuyển đến vị trí mới.
   • [Đường dẫn B: Không được sử dụng nếu bạn định sử dụng bước tùy chọn # 2.] Nếu cấu hình mạng và nguồn cho tất cả các máy giống hệt nhau: Đặt Machine3 trong đó Machine1 được lên kế hoạch kết thúc bằng các kết nối dành cho Machine1 .
   • Nhận Machine3 sao lưu và chạy. Ở vị trí mới, xác minh rằng nó hoạt động bình thường như một tấm gương của Machine2 . Điều này sẽ cung cấp xác minh vật lý rằng cấu hình của tất cả các sự cố (nguồn, mạng, v.v.) là chức năng ở vị trí mới.
   • Giải quyết mọi vấn đề phát sinh.
   • Xác minh rằng Machine3 đã được đồng bộ hóa lại hoàn toàn với Machine2 trước khi tiến hành.

2. Đường dẫn A: (Tùy chọn):

   • Sử dụng Machine3 để kiểm tra tất cả các phương tiện dành cho Machine2 và Machine1 .
   • Tắt Machine3 xuống và chuyển / chuyển sang sử dụng vị trí / kết nối cho Machine2 , (xác minh đồng bộ hóa lại) sau đó Machine1 (xác minh đồng bộ hóa lại). Nếu bạn dự định thực hiện việc này, thì Machine3 ban đầu nên được thiết lập với các kết nối dành cho sử dụng cuối bởi Machine1 hoặc Machine2 , vì vậy bạn không thiết lập nó trước ở vị trí cuối cho Machine3 và sau đó thay đổi 3 lần, nhưng chỉ 2 bằng cách bắt đầu với nó bằng cách sử dụng các cơ sở của một trong các máy khác.
   • Xác minh rằng Machine3 đã được đồng bộ hóa lại hoàn toàn với Machine2 trước khi tiến hành.

3. Di chuyển máy2 .

   • Việc luyện tập của bạn với Machine3 sẽ giúp việc này mượt mà hơn rất nhiều.
   • Sao lưu Machine2 , sau đó tắt nó đi
   • Di chuyển Machine2 đến vị trí mới; tạo tất cả các kết nối
   • Giải quyết mọi vấn đề phát sinh.
   • Xác minh rằng Machine2 đã được đồng bộ hóa lại hoàn toàn với Machine3 trước khi tiếp tục.

4. [Đường dẫn B: Không cần thiết nếu bạn đã kiểm tra tất cả các kết nối với Machine3 trong bước tùy chọn # 2] Nếu bây giờ có Machine3 , nơi Machine1 sẽ kết thúc:

   • Tắt máy3 .
   • Di chuyển nó đến nơi dự định kết thúc (ra khỏi vị trí bạn định đặt Máy1 ).
   • Giải quyết mọi vấn đề phát sinh.
   • Xác minh rằng Machine3 đã được đồng bộ hóa lại hoàn toàn với Machine2 trước khi tiến hành.

5. Di chuyển máy1 .

   • Đã di chuyển cả Machine2 và Machine3 (và hy vọng đã kiểm tra các kết nối thực tế mà Machine1 sẽ sử dụng bằng cách cho Machine3 sử dụng chúng tạm thời), đây sẽ là bước di chuyển mượt mà nhất.
   • Sao lưu Machine1 , sau đó tắt nó đi
   • Di chuyển Machine1 đến vị trí mới; tạo tất cả các kết nối
   • Giải quyết mọi vấn đề phát sinh.
   • Nếu có sự cố xảy ra với các cơ sở ở vị trí mà Machine1 được cho là chiếm, bạn có tùy chọn sử dụng các cơ sở nơi Machine3 hiện đang nằm. Hy vọng rằng bạn đã có thể kiểm tra tất cả các cơ sở ở vị trí Machine1 bằng cách sử dụng nó cho Machine3 trong một thời gian (Đường dẫn A hoặc Đường dẫn B).

Nếu bất kỳ IP nào của máy chủ sẽ thay đổi sau đó và các kết nối được thực hiện với hộp SQL thông qua độ phân giải DNS thì bạn sẽ cần lên lịch thay đổi cho các bản ghi DNS cùng lúc với việc di chuyển.

Những điều bạn nên biết về phần mềm và cơ sở dữ liệu mạng nội bộ:

• Phần mềm mạng nội bộ có kết nối với Máy chủ SQL qua IP, NetBIOS hoặc DNS không?
• Các tài khoản người dùng SQL Server được sử dụng bởi phần mềm mạng nội bộ có xác thực giới hạn lưu lượng truy cập đến từ một IP không?
• Các nhân viên tại công ty của bạn có truy cập SQL Server trực tiếp từ bất kỳ bảng tính hoặc công cụ báo cáo nào không, nếu vậy, họ định nghĩa DSN như thế nào?

Nếu bạn không nhận được cùng một IP chính xác hoặc nếu bạn kết thúc trên một mạng con khác, bạn sẽ cần quyền truy cập để thay đổi mã nguồn hoặc tệp cấu hình cho bất kỳ ứng dụng nào kết nối với máy chủ SQL. Mọi người có thể dựa vào truy cập SQL không có giấy tờ và trực tiếp để báo cáo đột xuất.

Sử dụng máy chủ "Phục hồi thảm họa" của bạn. Chuyển qua chúng để xử lý tải trong khi bạn di chuyển các máy chủ sản xuất của mình. Với thiết bị DR được cấu hình đúng cách, bạn có thể di chuyển vào giữa ngày mà không thấy nhiều thời gian chết (tối đa 15 phút). Vì các máy chủ phục hồi thảm họa nên được cấu hình theo cách tương tự như các máy chủ sản xuất. Nếu bạn không có thiết bị DR, tôi khuyên bạn nên có chúng.

Hãy nghĩ về nó theo cách này: trong khi tàu hộ tống của bạn đang được điều chỉnh, hãy sử dụng minivan của bạn để vượt qua cả ngày.

Một điều tôi không nghĩ đã được đề cập là bảo mật vật lý của ngôi nhà mới của các máy chủ. Căn phòng được sử dụng trước đây là gì và ai có chìa khóa cho nó? Có bảo mật đầy đủ (hệ thống báo động, máy ảnh, vv).

Một số cân nhắc ngoài các câu trả lời khác:

• Các ứng dụng được liên kết với các ứng dụng khác bằng cách trao đổi dữ liệu hàng đêm theo tệp hoặc bằng cách sử dụng dịch vụ web? Hậu quả khi các ứng dụng không có sẵn là gì? Các ứng dụng liên quan có thể đối phó với điều này hoặc chúng có bị lỗi hoặc thậm chí tạo ra kết quả sai do thiếu thông tin từ các ứng dụng của bạn không?

• Là một thời gian chết có thể chấp nhận cho người dùng, công ty hoặc thậm chí khách hàng của bạn? Nó có thể kéo dài bao lâu?

• Tôi nghĩ rằng đó là một ý tưởng tốt để có một kế hoạch cho một rollback. Bạn có thể sử dụng nó trong trường hợp sự cố không thể giải quyết nhanh chóng, ví dụ như sự cố mạng. Bạn có thể sẽ cần phải giữ mover có sẵn cho trường hợp mang phần cứng trở lại.

• Các ứng dụng của bạn có dẫn đến lưu lượng truy cập mạng cao và mạng có phải được chuẩn bị cho việc này không (có lẽ là vấn đề khó xảy ra hơn nhiều so với các vấn đề với địa chỉ và tường lửa)? Nếu bạn có các ứng dụng thời gian thực (ví dụ: phần mềm hội nghị video) sẽ rất quan trọng.

• Các máy chủ phải vừa với giá đỡ máy chủ nếu bạn có.