Làm thế nào tôi có thể sử dụng một cách an toàn việc cung cấp lưu trữ mỏng?


19

Tôi có bộ lưu trữ cho phép tôi cung cấp số lượng nhỏ cho các khách hàng. Cái này có an toàn không? Các thực hành tốt nhất là gì?

Câu trả lời:


16

Nói chung, cho dù bạn đang nói về SCSI LUNs (SAN) hoặc hệ thống tệp mạng (NAS), lưu trữ được cung cấp mỏng là khi bạn nói với máy khách lưu trữ rằng nó có nhiều dung lượng hơn bạn thực sự phân bổ cho nó. Điều này không có rủi ro riêng, nhưng nếu bạn không có đủ dung lượng lưu trữ thực tế để cho phép mọi container duy nhất phát triển đến kích thước đầy đủ như đã hứa, điều đó được gọi là cung cấp quá mức và nó sẽ dẫn đến rủi ro.

Ưu điểm

Những lợi thế của cung cấp quá mức và cung cấp mỏng là hấp dẫn. Nhiều người tiêu dùng lưu trữ (máy chủ, người dùng chia sẻ tệp, v.v.) sẽ yêu cầu dung lượng lưu trữ lớn hơn nhiều so với nhu cầu ban đầu và tiếp tục đảm bảo họ có biên độ an toàn cho tăng trưởng khi họ phát triển. Một biên độ an toàn được cung cấp tập trung cho tăng trưởng hiệu quả hơn nhiều so với hàng trăm cái nhỏ. Việc sử dụng bộ lưu trữ cơ bản mà không cần quá mỏng / quá mức có thể rất thấp và điều này cho phép tỷ lệ sử dụng cao hơn.

Rủi ro

Tất cả các rủi ro của kịch bản này được liên kết với việc cung cấp quá mức. Bạn càng cung cấp quá nhiều, nguy cơ của bạn càng cao. Điều nguy hiểm là tiềm năng cho việc sử dụng tài nguyên lưu trữ để lấp đầy hoàn toàn bộ lưu trữ có sẵn, điều này thường sẽ khiến tất cả các container lưu trữ bị hỏng theo cách này hay cách khác. Hệ thống tập tin sẽ chỉ đọc hoặc ngoại tuyến và LUN sẽ ngoại tuyến.

Thực hành tốt nhất

Để có được những lợi ích của việc sử dụng cao hơn đi kèm với việc cung cấp quá mức trong khi giảm thiểu rủi ro, bạn cần liên tục theo dõi việc lưu trữ và có thể hành động khi được yêu cầu.

  • Sử dụng phần mềm để theo dõi và cảnh báo về điều kiện sử dụng hồ bơi. Nếu không có gì trong hộp sẽ làm điều này, hãy tự viết nó. Hầu hết lưu trữ hỗ trợ các lệnh CLI có thể được đọc bởi một tập lệnh mà bạn lên lịch để chạy thường xuyên. Tần suất phải đủ cao để không có nhóm nào của bạn có khả năng lấp đầy giữa các sự kiện bỏ phiếu.
  • Thiết lập một ngưỡng cơ sở. Tất cả các nhóm lưu trữ mới với các máy khách được cung cấp quá mức sẽ được áp dụng điều này theo mặc định. Ngưỡng này nên là một trong những bảo thủ nhất trong môi trường của bạn.
  • Đối với các hồ nhỏ hơn, sử dụng ngưỡng thấp hơn. Nếu bạn đưa ra cho mình 30% cảnh báo trên nhóm 100TB, bạn sẽ có nhiều thời gian để thêm đĩa hơn so với việc bạn có cảnh báo 30% trên nhóm 10TB, giả sử cả hai đều có khả năng đọc ghi với tốc độ như nhau.
  • Điều chỉnh ngưỡng lên nếu bạn ít cung cấp quá mức. Nếu bạn có một hồ bơi chỉ được cung cấp vượt quá 106%, thì việc sử dụng 70% sẽ không gây rủi ro nhiều như một hồ bơi có tỷ lệ vượt quá 200%.
  • Điều chỉnh ngưỡng của bạn dựa trên thời gian bạn cần thêm không gian vào nhóm. Trong cửa hàng của tôi, chúng tôi giữ bộ lưu trữ trực tuyến trong mỗi hộp được giữ lại để tăng trưởng trong bất kỳ nhóm nào và lưu trữ nhiều hơn trên kệ sẵn sàng để được cài đặt vào bất kỳ hộp lưu trữ nào. Chúng tôi làm điều này cho đủ loại lưu trữ mà chúng tôi có thể xử lý sự tăng trưởng trong bất kỳ nhóm nào.
  • Bất cứ nơi nào có thể và áp dụng, làm mỏng lưu trữ của bạn. Chống trùng lặp hoạt động để giảm mức sử dụng của bạn và nếu bạn đang sử dụng LUN, không nhận lại trang nào và các máy khách có thể thực hiện lưu trữ không phân bổ khi chúng xóa cả dữ liệu.

Chúng tôi đã đưa ra trích dẫn 'đăng ký' về cả năng lực được cung cấp so với tổng công suất. Nhưng cũng về mặt cung cấp không sử dụng so với không gian miễn phí. Vì vậy, trong ví dụ của bạn - sử dụng 70%, với 200% đăng ký - bạn đã nhận được 130% còn lại được cung cấp so với 30% dung lượng lưu trữ thực tế, mang lại cho bạn tỷ lệ đăng ký 433%. (trong đó '106% so với 70%' có nghĩa là 36%: 30% = 120%)
Sobrique

Chúng tôi không nói với khách hàng bất cứ điều gì về điều này, nhưng chúng tôi chắc chắn hạ thấp ngưỡng sẽ khiến chúng tôi thêm đĩa khi chúng tôi có dung lượng được cung cấp cao hơn.
Basil

Khoản bồi hoàn và báo cáo là một phần quan trọng để suy nghĩ, chắc chắn. Tôi thực sự có hai suy nghĩ - một mặt, nếu họ không cần biết và tin tưởng vào nhóm lưu trữ để tiếp tục với nó, thì đó - với suy nghĩ của tôi - là cách tốt nhất. Tuy nhiên, tôi đã gặp phải tình huống họ tin tưởng vào nhóm lưu trữ để tiếp tục với nó - cho đến khi đến lúc phải lấp đầy, và vì vậy hãy thử và trì hoãn đơn đặt hàng để mua thêm đĩa.
Sobrique

1
Chúng tôi đã quyết định rằng sẽ rất tốt nếu chuyển khoản tiết kiệm từ việc trở nên mỏng như nhau cho tất cả các khách hàng lưu trữ. Chúng tôi lập hóa đơn cho mỗi địa chỉ TB.
Basil

Chi phí hàng tháng hay vốn? Tôi đã bị vấp ngã sau đó, đơn giản vì rất khó để ước tính tỷ lệ theo tuổi thọ của dịch vụ. Nhưng có thể khá khó để thuyết phục kế toán rằng bạn không muốn làm mô hình chi tiêu vốn nữa.
Sobrique

9

Điểm và mục đích của việc cung cấp mỏng tương tự như lý do sử dụng bộ lưu trữ hợp nhất ở nơi đầu tiên - bằng cách hợp nhất, bạn có được dung lượng tối đa tốt hơn, với mức trung bình thấp hơn cần thiết.

Nhưng không có ảo tưởng - cung cấp mỏng là giả vờ phân bổ một cái gì đó, mà không thực sự làm như vậy. Có nhiều lý do điều này hữu ích. Hai cái chính là:

  • Sử dụng cao hơn - trừ khi khối lượng của bạn hoàn toàn đầy đủ, không gian đĩa bị lãng phí. Hầu hết các hệ thống không chạy ở mức đầy đủ 100% mọi lúc (và thường được coi là "gặp sự cố" nếu có).

  • Chi tiêu trả chậm - nếu tôi cung cấp cho bạn 10TB ngày hôm nay, nhưng bạn điền vào mức 2TB mỗi năm, tôi có thể trả ít hơn nếu tôi đợi trước khi mua đĩa.

Bạn có hai vấn đề phát sinh từ việc này:

  • hết đĩa quá nhanh - ai đó bắt đầu điền vào 'đĩa' của họ có thể chạy phần còn lại của doanh nghiệp ngoài không gian.

  • số lượng trục chính - mua ít đĩa hơn có nghĩa là bạn có ít trục chính hơn và do đó ít IOP hơn. Điều đó có nghĩa là đĩa của bạn sẽ chạy nóng hơn và hiệu suất của bạn sẽ tệ hơn.

Những điều tôi muốn đề xuất như là một thực tiễn tốt nhất để cung cấp mỏng:

  • Nhận quản lý 'mua trong' cho các rủi ro liên quan.
  • đặt tỷ lệ ghi đè 'chấp nhận được. (Đây là một quyết định rủi ro kinh doanh, vì vậy hãy đưa nó lên).
  • Cũng xem xét kích thước khối lượng cá nhân. Dung lượng 20TB có nhiều khả năng ngấu nghiến dung lượng hơn rất nhiều dung lượng 100 GB.
  • Có sẵn dung lượng (hoặc đơn đặt hàng) khi bạn bắt đầu chạy chậm (dựa trên 'không gian trống' hoặc 'kích thước âm lượng'. Bạn không nhận được nhiều cảnh báo rằng bạn sắp hết, và bạn có thể có thể 'Đợi đến khi quý / năm tài chính tiếp theo hoàn tất - bạn sẽ không mua công suất mới nữa, bạn sẽ hoàn lại công cụ bạn đã' bán '.
  • Xem xét khả năng tối đa lý thuyết của hệ thống lưu trữ của bạn. Hãy suy nghĩ thật kỹ về những gì bạn sẽ làm nếu đi qua nó.
  • chú ý đến hiệu suất của bạn IOP / thông lượng cả. Bạn có thể sẽ không nhận được phản hồi tốt cho 'bạn cần bao nhiêu hiệu suất'. Nhưng bạn có thể thấy bạn 'hết' hiệu suất nhanh hơn bạn có thể. Đặt ngưỡng cho điều này quá.
  • xem xét tính phí của bạn cho phù hợp. Bạn tiết kiệm tiền bằng cách cung cấp mỏng, nhưng bạn sẽ CẦN một số tiền lại để theo kịp mô hình cung cấp mỏng của bạn.

Tôi không thể phóng đại điểm cuối cùng đủ. Bạn cũng có thể có những khách hàng yêu cầu lưu trữ và không bao giờ sử dụng nó. Đó là số tiền bạn không chi tiêu và thể hiện sự tiết kiệm. Tuy nhiên, điều đó không giống với những khách hàng mất một thời gian để sử dụng nó (ví dụ: hơn một năm tài chính) - bạn tiết kiệm tiền bằng cách mua đĩa lớn hơn / rẻ hơn vào năm tới. Nhưng bạn sẽ không thoát khỏi việc 'bán' không gian phía trước và chỉ hy vọng rằng không ai từng sử dụng nó. Bạn cũng có thể sẽ lấp đầy toàn bộ lô theo thời gian, và bạn cần sẵn sàng để điền lại.


1
Trong cửa hàng của tôi, chủ sở hữu dữ liệu không hiển thị cho chủ sở hữu dữ liệu trừ khi họ yêu cầu. Chúng tôi đưa ra quyết định lưu trữ, nhưng hứa sẽ không bao giờ phá vỡ một hồ bơi.
Basil

1
Đó là một lựa chọn - và có lẽ là một lựa chọn hợp lý, với điều kiện là 'lưu trữ' sau đó không phải đấu tranh cho capex 'nhiều đĩa hơn'. Đó là một câu hỏi về chính trị và tài chính hơn :)
Sobrique
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.