Có một cách tốt để sao lưu một petabyte dữ liệu và lưu trữ nó?

Tôi bắt đầu thấy các máy khách có hàng trăm terabyte dữ liệu (trong bản cài đặt SQL Server). Khi tổng khối lượng dữ liệu trong một số doanh nghiệp tiếp cận các phân số có ý nghĩa của một petabyte, tôi muốn đưa ra cơ sở kiến ​​thức tập thể ngoài kia để xem mọi người xử lý mức độ dữ liệu đó đang làm gì để bảo vệ dữ liệu đó.

Vấn đề rõ ràng là việc lưu trữ nhiều bản sao lưu của nhiều dữ liệu đó rất tốn kém, sử dụng lưu trữ cấp doanh nghiệp, quái, thậm chí chỉ là RAID-5.

Các tùy chọn tôi thấy như sau:

1. Tạo một bản sao phản chiếu của dữ liệu trong một trung tâm dữ liệu khác và liên tục gửi các khác biệt cho nó (sử dụng bất kỳ cơ chế nào có sẵn cho nguồn dữ liệu của bạn - ví dụ: vận chuyển log hoặc phản ánh cơ sở dữ liệu với SQL Server)
2. Thực hiện sao lưu thường xuyên bằng thuật toán nén khổng lồ (có lẽ chỉ phù hợp nếu dữ liệu tự cho vay tốt để được nén nhiều )
3. Hãy sao lưu từng phần của các phần quan trọng / thay đổi của dữ liệu.
4. Đừng sao lưu dữ liệu và tin vào các vị thần tham nhũng.

Tôi đang thấy tùy chọn số 4 được chấp nhận là mặc định và là một chuyên gia HA / DR, điều đó thực sự đáng sợ, nhưng tôi khuyên gì thay thế? Tôi nghĩ rằng # 1 là cách tiếp cận tốt nhất, nhưng "Tôi không nghĩ vậy" là câu trả lời thông thường khi có bất kỳ lựa chọn thay thế nào ngoài # 4 và có thể # 3 được đề xuất.

Bây giờ, tất nhiên nó phụ thuộc vào tốc độ thay đổi và mức độ quan trọng của dữ liệu. Không cần phải trả lời vì tôi đã từng chịu trách nhiệm về tất cả các tính năng HA của SQL Server khi tôi làm việc tại Microsoft nên tôi rất thành thạo trong các đối số 'nó phụ thuộc' - đó là cụm từ dễ hiểu của tôi :-)

Tôi rất muốn nghe về bất kỳ lựa chọn thay thế nào tôi đã bỏ lỡ, hoặc nghe nói rằng mọi người khác đều ở trong cùng một chiếc thuyền và không có sự thay thế thực tế nào để chi nhiều tiền cho việc lưu trữ nhiều hơn.

Cảm ơn trước - tín dụng đáo hạn sẽ được trao cho tất cả các câu trả lời được suy nghĩ kỹ lưỡng và bày tỏ.

Tắt ý tưởng tường - là tất cả các thông tin được lưu trữ cần thiết hoặc thậm chí hữu ích?

Bao nhiêu là thông tin thực sự có giá trị? Rõ ràng là vô lý khi chi tiêu nhiều hơn trong bảo trì và quản lý hơn dữ liệu có giá trị.

Dữ liệu trong cơ sở dữ liệu có phù hợp để lưu trữ trong cơ sở dữ liệu không? Ví dụ: việc giữ các tệp lõi nhiều gigabyte được nén trong cơ sở dữ liệu của tổ chức hỗ trợ có thực sự mang lại lợi ích thực tế nào không?

Có rất nhiều dữ liệu trùng lặp trong cơ sở dữ liệu? Ví dụ, có một nghìn người giữ mười bản sao mỗi bản tin 10MB hàng tuần không?

Có một số dữ liệu có "ngày hết hạn" mà sau đó nó không cung cấp bất kỳ giá trị nào không? Quay trở lại ví dụ về tổ chức hỗ trợ, vì nhiều lý do, hầu như không có lợi ích gì trong việc giữ xung quanh các tệp cốt lõi của khách hàng hơn một vài tháng sau khi bản sửa lỗi được gửi.

Một suy nghĩ khác - là giữ cho nhiều dữ liệu mở công ty đến các khoản nợ. Một số dữ liệu người ta phải, theo luật, giữ. Tuy nhiên, một số dữ liệu nên được "băm nhỏ" vì những rủi ro được đặt ra nếu nó vô tình hoặc độc hại, được phát hành cho các bên không phù hợp.

Vâng, một tùy chọn khác là ảo hóa lưu trữ: một thiết bị nằm giữa máy chủ của bạn và SAN, như IBM SVC. SVC quản lý các bản sao SAN-to-SAN và có thể sao chép từ xa (mặc dù điều đó rõ ràng khá đau ở cấp độ petabyte trừ khi bạn có tốc độ thay đổi dữ liệu thực sự thấp và băng thông thực sự cao.)

Phần khó khăn là toàn bộ quá trình là vô hình đối với các máy chủ liên quan. Nếu bạn đang sử dụng SQL Server, bạn thiết kế các nhóm của bạn để giữ mọi thứ có tỷ lệ thay đổi thấp cùng nhau (như lưu trữ bán hàng từ> 3 năm trước) và những thứ có tỷ lệ thay đổi cao (như doanh số hiện tại) trên một nhóm riêng biệt. Chúng thậm chí không phải hoàn toàn chỉ đọc - bạn chỉ muốn thiết kế nó để bạn có thể sử dụng các phương pháp sao chép khác nhau cho mỗi nhóm fileg. Thiết bị SAN có thể đồng bộ lun qua mạng, băng hoặc qua SAN - nghĩa là bạn có thể vận chuyển các bộ phận của SAN qua lại. Điều này hiệu quả hơn với các thiết bị như LeftHand, nơi SAN được tạo thành từ một nhóm các đơn vị tham gia.

Sau đó, bạn có thể tự động đồng bộ hóa công cụ tốc độ thay đổi thấp qua dây và đồng bộ hóa tốc độ thay đổi cao với sneakernet. (Âm thanh giống như tôi đã bị ngược, nhưng đó là sự thật - bạn không thể đồng bộ hóa công cụ tốc độ thay đổi cao qua dây do âm lượng.) Ngay cả một số thiết bị cấp thấp có thể hỗ trợ điều này ngay bây giờ: LeftHand cho phép bạn sao chép sang thiết bị khác Các đơn vị LeftHand trong trung tâm dữ liệu của bạn và sau đó gửi chúng đến trung tâm dữ liệu ngoại vi của bạn. Cắm chúng vào, tham gia chúng vào phía xa bằng cách thay đổi IP và nhóm, và giờ đây chúng là một phần của SAN sao lưu từ xa của bạn. Mức doanh số của LeftHand về điều này thật tuyệt vời: thiết lập hai SAN của bạn song song trong trung tâm dữ liệu chính của bạn, đồng bộ hóa chúng, sau đó bạn có thể gửi các bộ phận của chúng cho trung tâm dữ liệu từ xa trong khi một số trong số chúng vẫn ở hiện tại của bạn trung tâm dữ liệu để giữ đồng bộ. Dần dần di chuyển '

Tôi đã không làm điều này ở cấp độ petabyte, mặc dù. Bạn biết những gì họ nói - về lý thuyết, trong lý thuyết và trong thực tế là như nhau. Trong thực tế...

Tùy chọn 1 đang phản chiếu, điều này gần như tồi tệ như # 4: bất kỳ lỗi nào làm hỏng dữ liệu và không được phát hiện ngay lập tức, sẽ làm hỏng cả hai bản sao.

Nếu dữ liệu là quan trọng, hãy xem xét các giải pháp chuyên dụng; đọc về các sản phẩm Shark của IBM, ví dụ, hoặc các sản phẩm cạnh tranh từ EMS, v.v. Chúng có các tính năng như Flash-copy, cho phép bạn tạo ngay một bản sao hợp lý của tệp mà không cần tăng gấp đôi yêu cầu đĩa; và sau đó bạn có thể sao lưu bản sao này vào (ví dụ) băng. Nhìn vào sao lưu băng robot là tốt.

Chỉ ra những người muốn lưu trữ Petabyte dữ liệu lưu trữ không rẻ.

Tôi phát ngán với việc mọi người than vãn về việc không có thêm Terabyte dung lượng lưu trữ trực tuyến vì đĩa rất rẻ - có thể là đĩa, nhưng lưu trữ được quản lý chắc chắn là không có địa ngục.

Nếu việc lưu trữ các bản sao lưu quá tốn kém thì việc lưu trữ dữ liệu một cách an toàn sẽ rất tốn kém, vì vậy giải pháp được đề xuất là không khả thi.

Một trong những lý do quan trọng nhất để có bản sao lưu là bảo vệ khỏi lỗi người dùng (hầu hết các sự cố lỗi phần cứng có thể được giải quyết bằng các giải pháp phần cứng) nhưng ngay cả phản ánh cơ sở dữ liệu cũng không bảo vệ được bảng bị rớt (OK, bạn có thể bảo vệ chống lại điều đó, nhưng nó vẫn có thể nhận được guff không thể điều khiển được vào DB của bạn - trừ khi lý do DB quá lớn là nó chỉ phát hành các phần chèn).

Như tôi thấy nó băng không còn là một giải pháp khả thi - bây giờ rẻ hơn khi chỉ làm việc với các mảng đĩa (mặc dù lưu trữ vật lý có thể khó xử). Vì vậy, tôi nghĩ rằng tùy chọn duy nhất của bạn là một số phương pháp chia dữ liệu thành các phần nhỏ đủ để được khôi phục trong khung thời gian hợp lý và sau đó đưa chúng vào lưu trữ đĩa một cách thường xuyên (và ở đây các giải pháp loại EMS có thể giúp đỡ, nếu bạn đã có tiền mặt).

Video thú vị chi tiết kiến ​​trúc của myspace.com (phụ trợ SQL2005). Không chắc chắn nếu họ có dbs petabyte cá nhân khi họ mở rộng ra với nhiều dbs. Họ sử dụng sao lưu SAN snap.

http://wtv.watchTechideo.com/topic70.html

ZFS. Chắc chắn, nó vẫn chỉ mới bắt đầu, nhưng có một số lĩnh vực mà ZFS được thiết kế để xử lý những thứ này. Trước hết, khả năng xử lý một lượng lớn dữ liệu, cũng như vô số thiết bị lưu trữ khác nhau (cục bộ, SAN, sợi, v.v.), tất cả trong khi giữ dữ liệu an toàn với tổng kiểm tra và nhận thức "vi phạm lớp" về sức khỏe của thiết bị và thất bại. Làm thế nào mặc dù điều này giúp giải quyết sao lưu nhiều dữ liệu này?

Một phương pháp là sử dụng ảnh chụp nhanh. Chụp ảnh nhanh, gửi nó đến băng / đĩa / mạng để chuyển đến trang web từ xa. Ảnh chụp nhanh sau đó chỉ gửi dữ liệu đã được gửi và bạn có thể giữ dữ liệu trực tiếp ở cả hai đầu nếu cần.

Cách khác là sử dụng phần mềm Solaris Cluster trong đó (miễn là bạn có băng thông mạng hiệu quả), bạn có thể phản chiếu trực tiếp giữa hai máy chủ và nếu máy chủ ngừng hoạt động, thì thứ hai có thể tiếp quản. Nó được sử dụng nhiều hơn khi tính sẵn sàng cao (HA) là quan trọng, nhưng tôi đoán rằng hầu hết các địa điểm có nhiều dữ liệu đó đều muốn HA.

Và bạn nói rằng ZFS không được hỗ trợ trên Windows, nơi thông thường bạn có thể tìm thấy máy chủ sqls, có thể bạn chạy Sun / ZFS trên phụ trợ và kết nối qua iSCSI. Có lẽ đó cũng là một ý tưởng tồi tệ, nhưng ít nhất nó cũng đáng để bạn suy nghĩ để bạn biết những điều không nên làm.

Bạn đã xem Amazon Glacier như một lựa chọn chưa?

IMO, trừ khi bạn có một số loại phần cứng cấp Godzilla, nếu bạn có nhiều dữ liệu đó, bạn nên sử dụng công nghệ nén sao lưu. Tôi quen thuộc nhất với LiteSpeed, nhưng có những sản phẩm tương tự từ các nhà cung cấp khác và (tất nhiên) một tính năng tương tự được tích hợp trong SQL2008. Bạn có thể không nhận được nén 10 đến 1, nhưng nó cắt giảm yêu cầu lưu trữ để sao lưu xuống và cũng có thể thu nhỏ các yêu cầu cửa sổ sao lưu của bạn. Nếu mục tiêu của bạn là giữ nhiều bộ sao lưu (ngày hôm qua cộng với ngày trước đó, cộng với một bộ từ tuần trước và một bộ từ tháng trước hoặc một loạt các khác biệt cộng với đầy đủ, có thể trở nên lớn nếu bạn thay đổi nhiều dữ liệu trong cơ sở dữ liệu), đó là một vấn đề đơn giản về không gian lưu trữ.

Sao lưu dựa trên Filegroup (IOW, đưa dữ liệu không bay hơi vào một số FG nhất định và không thường xuyên quay lại) dường như không bao giờ bay vì các nhà phát triển hoặc người dùng sẽ không hoặc không thể quyết định dữ liệu nào dễ bay hơi và không phải là gì và trong trường nâu kịch bản bạn thường không thể mạo hiểm.

Nếu một trang web chuyển đổi dự phòng là một yêu cầu, ngoài việc nghĩ về Cơ sở dữ liệu), bạn có thể muốn nói chuyện với nhà cung cấp lưu trữ của khách hàng để xem họ có cung cấp thứ gì đó như SRDF, một công nghệ sao chép dữ liệu dựa trên phần cứng hay không. Đương nhiên, sao chép (dưới bất kỳ hình thức nào, nhưng đặc biệt là sao chép thời gian thực hoặc gần thời gian thực) không phải là sự thay thế cho các bản sao lưu.

Tôi không nghĩ rằng bạn có nhiều sự lựa chọn ở đây trên đĩa băng v. Băng sẽ không có khả năng cắt nó trong một cửa sổ sao lưu thông thường trừ khi bạn sọc nó và tôi không chắc độ tin cậy ở đó.

Vì vậy, bạn đang xuống để sao lưu đĩa. Bạn đang phiên bản? Có nghĩa là bạn lo lắng về việc quay lại bản sao lưu 2 (db hiện tại trừ 2 bản sao lưu)? Hoặc sao lưu 3? Trong trường hợp đó, bạn có thể gặp sự cố, nhưng có thể những gì bạn phải xử lý là sao lưu nhật ký, không phải sao lưu dữ liệu quá nhiều.

Nếu bạn có thể tách một số dữ liệu thành chỉ đọc / không thay đổi, thì có lẽ bạn có kích thước / cửa sổ sao lưu có thể quản lý được. Hoặc ít nhất bạn đang hy vọng rằng công nghệ sao lưu và băng thông đang bắt kịp với sự tăng trưởng dữ liệu.

Tôi không nghĩ rằng bạn đang sao lưu nhiều như bạn đang giữ một bản sao thứ 2 để phục hồi từ các vấn đề với chính của bạn. Điều đó có nghĩa là phần cứng, tham nhũng, v.v., và bạn đang cầu nguyện hàng ngày rằng các lỗi không được chuyển sang bản sao thứ hai. Các bản sao rất có thể đang được tạo ra SAN-SAN, với một số công nghệ chụp nhanh. mặc dù bản gốc có thể thông qua Fed-Ex chứ không phải qua dây. Băng thông để di chuyển 100TB không phải là điều dễ dàng đối với bất kỳ ai.

Tôi nghĩ rằng bạn cần kết hợp 1, 2 và 3 (không phải 4), với quản lý sao lưu nhật ký tuyệt vời.

Trên thực tế tôi nghĩ rằng bất cứ lúc nào bạn thực sự nhìn vào 3 bản sao dữ liệu của bạn. Chạy CHECKDB trên 1 trong số các bản sao trong khi bản sao thứ 2 đang được sử dụng để thực sự nhận được các thay đổi. Sau đó, bạn chụp lại bản sao thứ 2 đó đến bản đầu tiên và tiếp tục. Với nhiều dữ liệu này, tôi tưởng tượng rằng bạn sẽ cần một chút siêng năng ở đây. Paul, checkdb hoạt động như thế nào trên db nhiều người dùng, 100TB db đang trực tuyến?

Như đã đề cập, không sao lưu nhật ký, và có lẽ là một trình đọc nhật ký, quan trọng? Bạn không cần khôi phục lỗi thả bảng / lỗi người dùng từ nhật ký chứ không phải là bản sao lưu? Bạn có khả năng có thể tắt điều này bằng cách gửi các bản sao SAN thông qua một số chậm trễ, nhưng tôi chưa thấy công nghệ đó. Nhật ký vận chuyển SAN có thể trì hoãn thay đổi trong 4 giờ (hoặc một khoảng thời gian) để cho phép bạn khôi phục các sự cố trước khi ghi đè dữ liệu. Hoặc một số công cụ thay đổi log-reader-of-SAN? Nếu không có điều đó, bạn cần quản lý các nhật ký giao dịch đó, có thể là một cấp độ khác để theo dõi các bản sao lưu đó trên các hệ thống tệp khác nhau trong một số giờ xxx để cho phép bạn có khả năng phục hồi từ các lỗi không nghiêm trọng.

Về mặt kỹ thuật, lưu trữ là giá rẻ, nhưng ở cấp độ petabyte, không quá nhiều. Nó thực sự phụ thuộc vào ứng dụng, nhưng tôi muốn nói rằng sự kết hợp giữa chiến lược # 2 và # 3 sẽ là câu trả lời, với # 2 là nhất định và # 3 tùy thuộc vào số tiền bạn có thể đầu tư vào lưu trữ và loại lưu trữ và IO / sức mạnh tính toán sẽ cho phép bạn thoát khỏi với sự gia tăng ít nhất và càng kín đáo, sao lưu đầy đủ càng tốt.

Ngoài ra, một cái gì đó như Amazon S3 cũng có thể hoạt động tùy thuộc vào băng thông của bạn và mức độ thay đổi của dữ liệu - với khối lượng này, đặt ít nhất một số dữ liệu đó lên máy chủ của người khác và khiến họ lo lắng về sự dư thừa ngày càng nhiều chi phí hiệu quả.

Nói chuyện với nhà cung cấp lưu trữ của bạn, họ sẽ có một sản phẩm chống trùng lặp mà họ đã sử dụng trước đó, kết hợp với nén thông thường, bạn thường có thể giảm 70% dấu chân dữ liệu của mình. Tất nhiên, bất cứ ai có tiền để chi cho một petabyte lưu trữ cũng có khả năng có ngân sách để mua một giải pháp sao lưu hợp lý - nếu họ không có thì bạn chỉ cần hỏi họ rằng việc mất petabyte đó sẽ khiến họ mất gì.

Trong kho dữ liệu doanh nghiệp lớn, phần lớn dữ liệu đến từ các nguồn đã được sao lưu. Tôi đã làm việc trên các cài đặt Teradata và ODW nơi họ đã chọn tùy chọn # 4, nhưng biết rằng họ có thể khôi phục một hoặc hai ngày dữ liệu giao dịch và chuyển đổi nó từ các hệ thống nguồn.

Tại một khách hàng bán lẻ (tại thời điểm họ có một trong 5 DW lớn nhất thế giới, khoảng 200TB ... cho bạn ý tưởng về việc này cách đây bao lâu), họ đã chọn tùy chọn số 1 sau khi mua Petabyte mới -Máy chủ siêu dữ liệu. Các nút cũ sẽ được sử dụng để chụp nhanh hệ thống của ngày trước, trong khi nút mới duy trì trạng thái hiện có. Điều này cũng tốt từ góc độ chuyển đổi dự phòng - thỉnh thoảng họ sẽ gỡ toàn bộ để bảo trì và chúng tôi chỉ chuyển sang sử dụng máy chủ chậm cũ với dữ liệu cũ.

Thành thật mà nói, có vẻ như một sự lãng phí lớn đối với việc xử lý / lưu trữ / vv để giữ cho mọi thứ diễn ra ... đặc biệt khi lợi thế lớn nhất là quản trị viên và công nghệ NCR của họ phải làm việc ít buổi tối hơn để thực hiện bảo trì bất thường.