Không chú ý đến SAN đằng sau bức màn

Ngày xưa, tôi đã xây dựng các máy chủ SQL của riêng mình và kiểm soát cấu hình ổ đĩa, cấp độ RAID, v.v ... Lời khuyên truyền thống về phân tách dữ liệu, nhật ký, tempdb, sao lưu, (tùy thuộc vào ngân sách!) Luôn là một phần khá quan trọng của quá trình thiết kế máy chủ SQL.

Bây giờ với SAN cấp doanh nghiệp, tôi chỉ yêu cầu một dung lượng ổ đĩa cụ thể cho máy chủ SQL mới, được chia thành các ổ đĩa logic cho dữ liệu, sao lưu và lưu trữ tệp. Chắc chắn làm cho công việc của tôi dễ dàng hơn, nhưng có một phần trong tôi không cảm thấy hoàn toàn thoải mái khi tôi không thể nhìn trộm "đằng sau bức màn" để xem những gì đang thực sự xảy ra ở đó.

Tôi hiểu rằng nhóm SAN không cấu hình các "loại" ổ đĩa khác nhau khác nhau (tối ưu hóa ổ đĩa dữ liệu để truy cập ngẫu nhiên so với ổ đĩa nhật ký để ghi luồng). Một số điều này có thể phụ thuộc vào chính sản phẩm SAN (chúng tôi có HP XP12000 và HP XP24000), nhưng tôi đã chắc chắn rằng phần mềm HP thực hiện tất cả các loại cấu hình hiệu suất động (xem các điểm nóng IO và cấu hình lại khi đang di chuyển tối ưu hóa các LUN đó), để các nhóm ứng dụng và DBA không cần phải lo lắng về bất kỳ nội dung nào trong số đó. Một cái gì đó về "trải tải của tất cả các máy chủ trên một số lượng lớn các trục chính" hoặc một cái gì đó tương tự.

Câu hỏi / thảo luận của tôi:

1. Không làm kẻ thù trong nhóm SAN, làm cách nào tôi có thể trấn an bản thân và các nhà phát triển ứng dụng rằng các máy chủ SQL của chúng tôi không bị lưu trữ được cấu hình kém? Chỉ cần sử dụng số liệu thống kê perfmon? Điểm chuẩn khác như sqlio?

2. Nếu tôi tải thử nghiệm trên các ổ đĩa SAN này, điều đó có thực sự mang lại cho tôi một thước đo đáng tin cậy, có thể lặp lại về những gì tôi sẽ thấy khi chúng tôi phát hành trực tuyến không? (giả sử rằng phần mềm SAN có thể "cấu hình động" khác nhau tại các thời điểm khác nhau.)

3. IO nặng trong một phần của SAN (nói máy chủ Exchange) có ảnh hưởng đến máy chủ SQL của tôi không? (giả sử họ không cung cấp đĩa chuyên dụng cho mỗi máy chủ, điều mà tôi đã nói là không)

4. Sẽ yêu cầu phân tách các ổ đĩa logic cho các chức năng khác nhau Các ổ đĩa logic (dữ liệu so với nhật ký và tempdb) ở đây? SAN sẽ thấy hoạt động IO khác nhau trên đó và tối ưu hóa cấu hình chúng khác nhau?

5. Chúng ta đang ở trong một chút khủng hoảng không gian ngay bây giờ. Các nhóm ứng dụng được yêu cầu cắt lưu trữ dữ liệu, v.v. Liệu các mối lo ngại về không gian có khiến nhóm SAN đưa ra các quyết định khác nhau về cách họ định cấu hình bộ nhớ trong (cấp RAID, v.v.) có thể ảnh hưởng đến hiệu suất máy chủ của tôi không?

Cảm ơn những suy nghĩ của bạn (chủ đề tương tự được thảo luận ngắn gọn trong câu hỏi SF này )

Không làm kẻ thù trong nhóm SAN, làm cách nào tôi có thể trấn an bản thân và các nhà phát triển ứng dụng rằng các máy chủ SQL của chúng tôi không bị lưu trữ được cấu hình kém? Chỉ cần sử dụng số liệu thống kê perfmon? Điểm chuẩn khác như sqlio?

Nói tóm lại, có lẽ không có cách nào để thực sự chắc chắn. Điều tôi muốn nói (tôi là quản trị viên SAN), là nếu các ứng dụng của bạn hoạt động đúng với mong đợi của bạn, đừng lo lắng về điều đó. Nếu bạn bắt đầu thấy các vấn đề về hiệu suất mà bạn tin rằng có thể liên quan đến hiệu suất SAN / Disk IO, thì có thể nên hỏi thăm. Tôi không sử dụng nhiều bộ nhớ HP như bạn, nhưng trong thế giới IBM / NetApp tôi có thể nói từ kinh nghiệm rằng không có nhiều tùy chọn cho phép bạn định cấu hình nó "kém". Hầu hết lưu trữ doanh nghiệp ngày nay mất rất nhiều phỏng đoán trong việc xây dựng các mảng đột kích và không thực sự cho phép bạn làm sai. Trừ khi họ đang trộn tốc độ và dung lượng ổ đĩa trong cùng một nhóm đột kích, bạn có thể yên tâm trong hầu hết các trường hợp đĩa của bạn hoạt động tốt.

Nếu tôi tải thử nghiệm trên các ổ đĩa SAN này, điều đó có thực sự mang lại cho tôi một thước đo đáng tin cậy, có thể lặp lại về những gì tôi sẽ thấy khi chúng tôi phát hành trực tuyến không? (giả sử rằng phần mềm SAN có thể "cấu hình động" khác nhau tại các thời điểm khác nhau.)

Kiểm tra tải nên rất đáng tin cậy. Chỉ cần lưu ý rằng khi bạn đang tải thử nghiệm một hộp, trên một SAN / Disk Array được chia sẻ, hiệu suất của nó có thể (và sẽ) bị ảnh hưởng bởi các hệ thống khác sử dụng cùng một bộ lưu trữ.

IO nặng trong một phần của SAN (nói máy chủ Exchange) có ảnh hưởng đến máy chủ SQL của tôi không? (giả sử họ không cung cấp đĩa chuyên dụng cho mỗi máy chủ, điều mà tôi đã nói là không)

Nó có thể. Nó không phải là tất cả về các đĩa, hoặc các đĩa, các máy chủ đang bật. Tất cả dữ liệu đang được cung cấp thông qua bộ điều khiển đĩa và sau đó là công tắc SAN. Hiệu suất bạn sẽ thấy rất nhiều phụ thuộc vào cách bộ điều khiển đĩa được kết nối với các kệ đĩa tương ứng và SAN tương ứng. Nếu toàn bộ mảng kết nối với SAN xương sống trên một sợi quang 4gbps, thì rõ ràng hiệu suất sẽ bị ảnh hưởng. Nếu mảng được kết nối qua hai SAN dự phòng được cân bằng tải, sử dụng các liên kết trung kế, thì không thể trao đổi một mình để hút quá nhiều băng thông. Một điều khác cần được xem xét là có bao nhiêu IO / giây mà mảng có khả năng. Miễn là mảng và SAN được kết nối được chia tỷ lệ chính xác,

Sẽ yêu cầu phân tách các ổ đĩa logic cho các chức năng khác nhau Các ổ đĩa logic (dữ liệu so với nhật ký và tempdb) ở đây? SAN sẽ thấy hoạt động IO khác nhau trên đó và tối ưu hóa cấu hình chúng khác nhau?

Đó có lẽ là vấn đề ưu tiên và cũng phụ thuộc rất nhiều vào cách quản trị viên lưu trữ của bạn định cấu hình nó. Họ có thể cung cấp cho bạn ba LUN trong cùng một mảng hoặc âm lượng, trong trường hợp đó tất cả đều giống nhau. Nếu họ đưa cho bạn các LUN riêng lẻ trên các mảng khác nhau, trong các ổ đĩa khác nhau (các đĩa vật lý khác nhau), thì có thể đáng để bạn tách chúng ra.

Chúng ta đang ở trong một chút khủng hoảng không gian ngay bây giờ. Các nhóm ứng dụng được yêu cầu cắt lưu trữ dữ liệu, v.v. Liệu các mối lo ngại về không gian có khiến nhóm SAN đưa ra các quyết định khác nhau về cách họ định cấu hình bộ nhớ trong (cấp RAID, v.v.) có thể ảnh hưởng đến hiệu suất máy chủ của tôi không?

Tôi không tưởng tượng quản trị viên lưu trữ của bạn sẽ thay đổi cấp độ đột kích để giải phóng không gian. Nếu anh ta muốn, thì có lẽ anh ta nên bị sa thải. Mối quan tâm về không gian có thể khiến mọi thứ được cấu hình khác nhau, nhưng thông thường không theo cách ảnh hưởng đến hiệu suất. Họ có thể trở nên chặt chẽ hơn một chút về việc họ dành cho bạn bao nhiêu không gian. Họ có thể kích hoạt các tính năng như sao chép dữ liệu (nếu mảng hỗ trợ nó) có thể cản trở hiệu suất của mảng trong khi quy trình chạy, nhưng không phải xung quanh đồng hồ.

Nhóm SAN nên có các công cụ có thể giúp bạn tiết lộ nếu ứng dụng của bạn là điểm nóng. Rõ ràng, bạn cũng nên theo dõi và đo lường kết thúc của bạn.

Hầu hết kinh nghiệm của tôi là với EMC nên YMMV. Nhưng những điều sau đây nên áp dụng cho hầu hết các thiết bị SAN.

Chỉ có rất nhiều cổng đi vào mảng. Đôi khi có một chuyển đổi SAN ở giữa mà bạn có thể xác định vùng. Chỉ vì mảng thực chất là một kho lưu trữ lớn không có nghĩa là bạn không nên lo lắng về hiệu suất IO.

Vì vậy, nếu bạn cảm thấy rằng bạn đang gặp vấn đề về IO, bạn cần thu hẹp nơi tắc nghẽn. Nếu nó nằm ở đâu đó giữa HBA và mảng, thì bạn có thể tìm hiểu xem HBA có được tối đa hóa không hoặc nếu cổng SAN ở phía chuyển đổi / mảng được đăng ký vượt mức. Ngoài ra, bạn nên có nhóm SAN theo dõi các mẫu truy cập cho ứng dụng của mình, cả khi bắt đầu lạnh và chạy nóng.

Rõ ràng, bộ lưu trữ bên dưới tạo ra sự khác biệt khi chạy RAID5 chậm so với RAID10 tốc độ vì đôi khi bạn sẽ phải nhấn vào đĩa bất kể các cấp độ bộ đệm khác nhau.

HTH. Bạn có thể ping tôi ngoại tuyến nếu bạn gặp sự cố cụ thể vì việc này có thể mất một lúc để xử lý.

Không làm kẻ thù trong nhóm SAN, làm cách nào tôi có thể trấn an bản thân và các nhà phát triển ứng dụng rằng các máy chủ SQL của chúng tôi không bị lưu trữ được cấu hình kém? Chỉ cần sử dụng số liệu thống kê perfmon? Điểm chuẩn khác như sqlio?

Điều đầu tiên bạn cần biết trước khi thực hiện bất kỳ loại điểm chuẩn nào là khối lượng công việc của bạn cần phải chịu đựng. Vì vậy, hãy chuẩn hóa công cụ của riêng bạn trước khi kiểm tra hệ thống mới. Bằng cách đó, nếu bạn thấy bạn đang đẩy tối đa 56 MB / giây trong khi tải tối đa (sao lưu?), Phát hiện ra rằng mảng đĩa gắn SAN 'chỉ' đẩy 110 MB / giây dưới tải tối đa mô phỏng, bạn có thể đảm bảo rằng giới hạn sẽ không phải là kênh I / O.

Khi kiểm tra một mảng đĩa mới, tôi đã thực hiện loại thử nghiệm hiệu năng này. Mảng mới đã sử dụng ổ đĩa SATA thay vì ổ đĩa sợi quang (SCSI) và tôi cần tự đảm bảo rằng nó sẽ hoạt động trong môi trường của chúng tôi. Tôi đã vô cùng mơ hồ. Nhưng sau khi mô tả đặc điểm, tôi phát hiện ra rằng hệ thống mới có đủ chi phí I / O dưới đỉnh để theo kịp đỉnh đo được trên các đĩa đáng tin cậy hơn. Nó làm tôi ngạc nhiên.

Nếu tôi tải thử nghiệm trên các ổ đĩa SAN này, điều đó có thực sự mang lại cho tôi một thước đo đáng tin cậy, có thể lặp lại về những gì tôi sẽ thấy khi chúng tôi phát hành trực tuyến không? (giả sử rằng phần mềm SAN có thể "cấu hình động" khác nhau tại các thời điểm khác nhau.)

Do tính chất chia sẻ của mảng đĩa đính kèm SAN, hiệu suất thay đổi theo tuần. Nếu bạn đã biết khi nào tải I / O cao nhất của bạn là, hãy thực hiện một loạt các thử nghiệm tải trong thời gian trong ngày khi tải I / O cao nhất của bạn là. Bằng cách đó, bạn có thể mô tả rõ hơn loại I / O nào có sẵn trong khoảng thời gian bạn quan tâm nhất. Tải thử nghiệm trong thời gian không cao điểm sẽ cho bạn cảm giác về những thứ 'linh hoạt' sẽ đạt được, nhưng thử nghiệm cao điểm sẽ cung cấp cho bạn kiểm tra giới hạn thực sự.

IO nặng trong một phần của SAN (nói máy chủ Exchange) có ảnh hưởng đến máy chủ SQL của tôi không? (giả sử họ không cung cấp đĩa chuyên dụng cho mỗi máy chủ, điều mà tôi đã nói là không)

Nếu Exchange LUN chia sẻ đĩa với SQL LUN ​​của bạn, họ hoàn toàn sẽ làm được. Chúng tôi sử dụng HP EVA, không phải XP, nhưng tôi nghĩ họ sử dụng thuật ngữ "nhóm đĩa" giống nhau. Các LUN trong cùng một nhóm chia sẻ đĩa, và do đó tranh giành I / O trên các thiết bị vật lý đó. Càng nhiều đĩa bạn đặt vào một nhóm đĩa, mảng càng lung tung thì mảng phải lộn xộn I / O. Các mảng (ít nhất là của eva làm điều này và tôi cho rằng các XP đắt tiền hơn cũng làm như vậy) phân phối các khối LUN logic trên các đĩa vật lý theo cách không tuần tự. Điều này cho phép nó thực hiện những gì bạn đề xuất, đó là phân phối động các nhóm khối thường xuyên truy cập đến các thiết bị vật lý khác nhau để tăng tính song song và giảm tranh chấp I / O ở cấp độ đĩa.

Câu hỏi cần đặt ra là nhóm đĩa đó có bao nhiêu ngân sách, và liệu các ứng dụng sử dụng các LUN đó có được đăng ký vượt mức cho I / O hay không. Đó là một câu hỏi mà các quản trị viên lưu trữ sẽ phải theo dõi. Có thể là I / O cao nhất cho Exchange (có thể trong quá trình sao lưu) có thể không trùng với tải SQL và cả hai hệ thống có thể cùng tồn tại hạnh phúc.

Sẽ yêu cầu phân tách các ổ đĩa logic cho các chức năng khác nhau Các ổ đĩa logic (dữ liệu so với nhật ký và tempdb) ở đây? SAN sẽ thấy hoạt động IO khác nhau trên đó và tối ưu hóa cấu hình chúng khác nhau?

Đối với mảng HP, bạn cần đặt các mẫu I / O khác nhau vào các nhóm đĩa khác nhau không phải LUN. Chẳng hạn, các mẫu I / O của cơ sở dữ liệu không cùng tồn tại với các mẫu truy cập phục vụ web. Các LUN khác nhau không cải thiện đáng kể hiệu suất của bạn trừ khi chúng thuộc các nhóm đĩa khác nhau. Nếu chúng nằm trong cùng một nhóm đĩa, lợi thế thực sự duy nhất là hệ điều hành, nơi nó có thể lập lịch I / O trong kernel để cải thiện tính song song với hệ thống con đĩa. Mà nói...

Theo hiểu biết của tôi, mảng HP, nhận thức được các kiểu truy cập khác nhau trên LUN, nhưng chú ý đến các khối logic thực tế. Đặt nhật ký vào một LUN khác sẽ đặt ràng buộc vào các khối logic sẽ có loại lưu lượng I / O đó và điều đó sẽ giảm bớt nhiệm vụ sắp xếp chính xác các khối logic trên các đĩa vật lý.

Chúng ta đang ở trong một chút khủng hoảng không gian ngay bây giờ. Các nhóm ứng dụng được yêu cầu cắt lưu trữ dữ liệu, v.v. Liệu các mối lo ngại về không gian có khiến nhóm SAN đưa ra các quyết định khác nhau về cách họ định cấu hình bộ nhớ trong (cấp RAID, v.v.) có thể ảnh hưởng đến hiệu suất máy chủ của tôi không?

Chắc chắn rồi. Nếu không gian chật hẹp, bạn sẽ không nhận được các nhóm đĩa chuyên dụng cho I / O của mình (trừ khi môi trường lưu trữ của bạn đủ lớn để chứng minh việc dành 7TB đĩa vật lý cho mục đích sử dụng riêng của bạn, tại thời điểm đó có thể là trường hợp ). Cuộc tranh luận về Raid5 / Raid10 phụ thuộc phần lớn vào các chính sách của tổ chức và yêu cầu là đặt cược tốt nhất của bạn.

Tôi đề nghị mở một hộp thoại với Nhóm SAN và nhà cung cấp của bạn để giải quyết các mối quan tâm của bạn. Một trong những vấn đề bạn sẽ gặp phải khi chạy điểm chuẩn của riêng mình là các bài kiểm tra của bạn có thể không liên quan đến những gì xảy ra trong sản xuất, đặc biệt là ở mức tải cao nhất. Hầu hết các SAN đều có hàng tấn bộ đệm được hỗ trợ bởi pin, trong nhiều trường hợp (đặc biệt là khi bạn chạy các điểm chuẩn tổng hợp) có nghĩa là bạn đang ghi vào RAM và nhận được hiệu năng kick-ass.

Tùy thuộc vào môi trường của bạn và giải pháp bạn đang sử dụng, một số nhà cung cấp CE có thể vừa bay vào và thiết lập SAN theo bất kỳ tiêu chuẩn nào anh ta thích. Điều đó xảy ra nhiều hơn bạn nghĩ. Bạn sẽ phải bỏ đi phần vỏ "nhóm SAN biết tất cả" cho đến khi bạn tin chắc rằng giải pháp đó đáp ứng yêu cầu của bạn.

Chúc may mắn.

Tôi đã có mặt tại một hội nghị tiên tri một lần với bài nói chuyện về chủ đề này - SAN lành mạnh cho cơ sở dữ liệu.

Ý chính của bài nói chuyện có sẵn trong tệp PDF này hoặc tại trang của tác giả ở đây