Điều gì nếu một cơn lốc xoáy đi qua trung tâm dữ liệu CỦA BẠN?

Cuối tuần qua chúng tôi đã có những cơn bão dữ dội ở Virginia và dĩ nhiên cuộc khủng hoảng ở Nhật Bản là một lời nhắc nhở rằng mọi thứ có thể trở nên tồi tệ trong tích tắc! Một câu hỏi tôi tự hỏi "Nếu cơn lốc xoáy tấn công trung tâm dữ liệu của tôi, tôi đã chuẩn bị chưa?"

Tôi có hệ thống sao lưu tuyệt vời "trong giá của tôi" bao gồm một bản sao lưu băng. Bởi vì trung tâm dữ liệu không đóng băng di chuyển khỏi trang web là không thể. Những gì tôi muốn tìm hoặc tạo là một hệ thống theo lịch có thể sao lưu các mục quan trọng như trang web, cơ sở dữ liệu và sao chép chúng từ xa, tức là máy chủ của tôi ở nhà. Tôi có FIOS với dịch vụ 35 mbit vì vậy tôi có băng thông rộng, cái tôi cần là "hệ thống" để làm việc này. Tôi là một lập trình viên vì vậy tôi có thể tạo ra thứ gì đó có thông tin về lịch trình của FTP, nhưng tôi tò mò liệu có thứ gì đó có thể đáp ứng nhu cầu sao lưu từ xa này không? Máy chủ SQL của tôi được sao lưu vào mảng lưu trữ, tôi có thể mang các bản sao lưu đó xuống hoặc thậm chí lên lịch cho máy chủ SQL của mình ở đây để đồng bộ hóa với các máy chủ sản xuất theo lịch trình. Tôi sử dụng Windows Server 2008 R2 và SQL Server 2008 R2.

Tất cả những gì bạn đề nghị cho chiến lược trang web trong một cuộc khủng hoảng như một thảm họa tự nhiên đánh bật trung tâm dữ liệu của chúng tôi? Ban chuẩn bị chưa? Tôi hy vọng những người khác tự hỏi mình câu hỏi này và học hỏi từ những thảm họa thiên nhiên mà chúng ta đã thấy quá thường xuyên.

Các tùy chọn của bạn nên được quyết định bởi các thỏa thuận cấp dịch vụ với khách hàng và bị giới hạn bởi ngân sách của bạn.

Ở mức tối thiểu, bạn nên có các bản sao lưu ngoài trang web của tất cả các dữ liệu quan trọng. Đó là ngày nay, bất kỳ dữ liệu nào bạn không thể tạo lại từ đầu cần phải được lưu trữ ở nơi khác. Sao lưu ngoại tuyến tốt hơn: sao lưu trực tuyến hoặc sao chép có thể giúp ích khi cơn lốc xoáy xảy ra, nhưng điều gì xảy ra nếu bạn có một nhân viên tức giận làm rơi cơ sở dữ liệu hoặc phá hủy hệ thống tệp?

Từ đường cơ sở của các bản sao lưu ngoại tuyến, bạn có thể bắt đầu khám phá các tùy chọn sẽ tăng tốc độ phục hồi để đổi lấy chi phí cao hơn. Có một số lượng lớn các tùy chọn ở đây, từ một máy chủ duy nhất cho các bản sao lưu trực tuyến mà bạn mô tả tất cả các cách đến các môi trường được sao chép hoàn toàn với sao chép dữ liệu đồng bộ đang hoạt động (hoạt động) + cho thời gian chết gần như bằng không.

Bạn sẽ thấy việc khôi phục từ đầu trở nên dễ dàng hơn nhiều nếu bạn tách dữ liệu khỏi cơ sở hạ tầng của mình một cách gọn gàng nhất có thể. Ví dụ, phục hồi từ đầu sẽ nhanh hơn nhiều, nhanh hơn nhiều nếu bạn triển khai sử dụng các hệ thống như con rối hoặc đầu bếp thay vì bằng tay. Làm lại tất cả các công việc bạn đã đưa vào xây dựng hệ thống của mình sẽ nhanh hơn nhiều nếu bạn có thể tự động hóa càng nhiều càng tốt. Giữ dữ liệu riêng biệt cũng làm giảm lượng dữ liệu bạn cần sao lưu: không quay vòng gigabyte hệ điều hành nếu bạn chỉ thực sự cần một vài megs cấu hình hệ thống và dữ liệu ứng dụng.

Các tùy chọn có thể có giá khá cao, vì vậy bạn cần xác định công ty của bạn sẵn sàng chi bao nhiêu cho việc khắc phục thảm họa và thời gian mà khách hàng của bạn có thể chịu đựng được. Loại bỏ các tùy chọn quá đắt hoặc quá chậm cho khách hàng của bạn.

Một khi bạn chọn một giải pháp khắc phục thảm họa, hãy chắc chắn rằng bạn thực hành nó. Tôi muốn giới thiệu ít nhất một lần một năm hoặc bất cứ khi nào kiến ​​trúc của bạn thay đổi, bất cứ điều gì xảy ra thường xuyên hơn.

Hoạt động kinh doanh liên tục tiến xa hơn nhiều so với việc đảm bảo bạn có quyền truy cập vào các bản sao lưu có thể đọc được. Nhưng chỉ giới hạn phạm vi của câu trả lời, cuối cùng sẽ chỉ khả thi khi băng thông đầu cuối từ trung tâm dữ liệu đến vị trí sao lưu đủ lớn để xử lý khối lượng thay đổi dữ liệu.

Khi bạn đang nói về một trung tâm dữ liệu, thì đối với hầu hết mọi người, đó là Gigayte dữ liệu mỗi tuần.

IME, ngay cả ở quy mô nhỏ, giải pháp tốt nhất là hoạt động phân tán (hoặc nhân đôi). Lập kế hoạch đúng và sẽ có ít chi phí hơn so với một trung tâm dữ liệu duy nhất.

Nhưng nếu bạn phải sao chép tất cả dữ liệu ra một vị trí chờ hoặc thậm chí chỉ để lưu trữ từ xa, thì

1) không sử dụng FTP - đó là cách làm sai vì nhiều lý do

2) cho các tệp chung, sử dụng cái gì đó như rsync được tối ưu hóa cho mục đích

3) đối với cơ sở dữ liệu, hãy xem các công cụ có sẵn dành riêng cho DBMS của bạn - cấu trúc tệp có thể thay đổi ồ ạt mà không cần thay đổi dữ liệu nhiều. NB điều này bao gồm MSWindows đăng ký và dữ liệu MSAD.

Chúng tôi có VPN từ văn phòng đến trung tâm dữ liệu ngoại vi của chúng tôi. Tại trung tâm dữ liệu ngoại vi, chúng tôi có máy chủ có chia sẻ mạng mà chúng tôi định cấu hình làm đích trong phần mềm sao lưu (chúng tôi chạy Symantec BackupExec), tức là \ OFFSITEDATACENTER \ OFFSITESTORAGE

Sau đó chúng tôi làm - một bản sao lưu đầy đủ vào cuối tuần đến vị trí đó
- tăng dần vào mỗi tối

Cũng như sao lưu "tại chỗ" bình thường của chúng tôi

Chúng tôi cũng chạy VMWare VDR để chụp ảnh các máy chủ chính của chúng tôi mỗi tuần, được đưa vào đĩa SATA 2TB được mã hóa bằng FreeOTFE mà tôi mang về nhà mỗi tuần.

Chúng tôi có một số trung tâm dữ liệu hoạt động / hoạt động hoặc hoạt động / bán chủ động riêng biệt với> 50 dặm giữa chúng, các nhà cung cấp điện khác nhau, an ninh, 10Gbps đa dạng-chuyển mesh liên kết giữa chúng, oh và chúng tôi tàu đĩa sao lưu của chúng tôi giữa chúng quá. Điều này không cho chúng tôi.

Các chi tiết cụ thể về việc xử lý một chương trình sao lưu nhất định đã được đề cập đến ở đây và các nơi khác. Tôi sẽ tiếp cận câu hỏi này từ quan điểm cấp cao hơn về các hướng dẫn chung để giúp bạn quyết định cách tiếp cận khắc phục thảm họa. Tôi đã ở trong một vài tình huống phải lập kế hoạch trong trường hợp trung tâm dữ liệu trở thành một miệng hút thuốc. Rất may, chúng tôi chỉ phải sử dụng một lần. Những điều quan trọng nhất cần nhớ là:

1) Đừng lãng phí thời gian của bạn để cố gắng áp đảo và khiến mọi thứ thất bại với độ chính xác <1ms nếu bạn không phải làm vậy. Một sự thất bại hoàn toàn của cường độ đó thường sẽ tha cho sự phục hồi trong vài giờ.

2) Là hệ quả của # 1, hãy đảm bảo rằng các kỳ vọng được xác định thực tế và được mã hóa trong một chính sách ở đâu đó. Có một mục tiêu đã đề ra để đạt được thời gian phục hồi là rất quan trọng, vì bạn có thể dành thời gian không giới hạn và việc kiếm tiền là "thậm chí tốt hơn".

3) Ưu tiên hệ thống của bạn. Kế hoạch phục hồi cần được xây dựng xung quanh một danh sách dứt khoát về tầm quan trọng của mỗi và mọi hệ thống. Đừng bỏ lỡ những điều hiển nhiên, như là nâng cấp DNS và AD trước các máy chủ Windows còn lại.

4) Nếu không phải là ngoại vi VÀ ngoài mạng, thì đó chỉ là một bản sao. Điều này phù hợp với một điều quan trọng khác cần nhớ: RAID không phải là một kế hoạch dự phòng.

5) Kiểm tra, kiểm tra, kiểm tra! Kiểm tra từng inch của kế hoạch của bạn mà bạn có thể. Nếu bạn có thể nhận được giá trị cuối tuần trong thời gian bảo trì, hãy ngắt kết nối đường lên và / hoặc sức mạnh xây dựng và kiểm tra thời gian và hiệu quả phản ứng của nhóm của bạn. Một kế hoạch khắc phục thảm họa chưa bao giờ được thử nghiệm chỉ là mơ tưởng.