Tệp máy chủ SQL cục bộ hoặc NAS hoặc SAN?

Tôi phải cài đặt Máy chủ mới với SQL Server 2008, Bạn khuyên gì, Một máy chủ có Raid 10 hoặc Tệp trong NAS?

Tôi nên sử dụng iSCSI thì sao?

Thế còn SAN?

Máy chủ có 4Gb RAM và tệp cơ sở dữ liệu đó khoảng 2GB.

Để làm cho tôi rõ ràng ngày hôm nay máy chủ không có RAID, tôi phải thực hiện một số loại chiến lược vì vậy nếu có chuyện gì xảy ra tôi có thể giữ các tệp của mình an toàn, vậy tôi nên chọn Local Files, NAS, SAN là gì? Tùy chọn nào có hiệu suất cao nhất, an toàn hơn là gì?

NAS

Chắc chắn không phải là NAS cho SQL Server. SMB / CIFS không có hỗ trợ đầy đủ cho việc khóa tệp để hỗ trợ DBMS (ít nhất là nó đã không hoạt động vài năm trước, khoảng năm 2002-2003). Lưu ý rằng NFS làm và bạn thực sự có thể làm điều này với Oracle trên máy chủ NFS. Tuy nhiên, SQL Server trên chia sẻ CIFS không đáng tin cậy do các hạn chế của giao thức. Nó thậm chí có thể không cho phép bạn đặt các tệp trên cổ phiếu được gắn CIFS.

SAN

Điều này tốt cho các ứng dụng giao dịch vì bộ đệm trên bộ điều khiển RAID có thể hấp thụ các bộ làm việc khá lớn. Bộ điều khiển RAID SAN thường hỗ trợ nhiều bộ đệm hơn bộ điều khiển RAID dựa trên máy chủ, đặc biệt là trên bộ công cụ cao cấp trong đó bộ điều khiển RAID có thể là hộp đa bộ xử lý mạnh như máy chủ.

SAN với bộ điều khiển kép cũng có kiến ​​trúc không có điểm thất bại duy nhất và cung cấp nhiều tùy chọn để sao lưu nóng. Điều này làm cho họ một chiến thắng từ quan điểm quản lý và độ tin cậy. Tuy nhiên, chúng rất tốn kém và bị hạn chế trong việc truyền khối lượng dữ liệu, mặc dù điều này không chắc là vấn đề trên hệ thống giao dịch.

Đối với các hệ thống hoạt động, SAN hầu như luôn là lựa chọn tốt nhất nếu có sẵn. Chúng cũng có thể được chia sẻ giữa nhiều máy chủ chạy các hệ thống âm lượng trung bình thấp. Tuy nhiên, chúng đi kèm với một thẻ giá đặt ràng buộc thấp hơn đáng kể trên hệ thống nhỏ nhất mà công nghệ có thể được sử dụng.

Đính kèm trực tiếp

Trong một số trường hợp, lưu trữ đính kèm trực tiếp là tốt nhất. Một khả năng là các ứng dụng phát trực tuyến bị hạn chế băng thông, trong đó số lượng kết nối kênh sợi bị giới hạn sẽ hạn chế băng thông khả dụng ở mức thấp hơn mức có thể với bộ điều khiển SAS cao cấp. Tuy nhiên, đây có thể là các ứng dụng khá chuyên biệt như kho dữ liệu rất lớn nơi kiến trúc không chia sẻ có thể cung cấp thông lượng tốt nhất.

Trong thực tế, lưu trữ đính kèm trực tiếp thường tốt hơn SAN cho các hệ thống kho dữ liệu vì một số lý do:

• Kho dữ liệu đặt các xung tải lớn thoáng qua trên các hệ thống con đĩa. Điều này làm cho họ khá chống đối xã hội trên SAN vì chúng có thể ảnh hưởng đến hiệu suất của các hệ thống khác trên SAN.

• Các nút cổ chai trực tuyến nói trên.

• Lưu trữ đính kèm trực tiếp rẻ hơn khá nhiều so với lưu trữ SAN.

Một thị trường khác cho lưu trữ đính kèm trực tiếp là khi bạn bán cho thị trường sẽ không trả đủ tiền cho SAN. Điều này thường đúng với các ứng dụng được bán cho khách hàng của SMB. Đối với một hệ thống điểm bán hoặc hệ thống quản lý thực hành sẽ có sáu người dùng, SAN có thể là quá mức cần thiết. Trong tình huống này, một máy chủ tháp độc lập nhỏ với một số đĩa bên trong là một giải pháp phù hợp hơn nhiều.

Địa phương hoặc SAN là cách duy nhất để duy trì hiệu suất. Trong một số trường hợp, SAN có thể nhanh hơn đĩa cục bộ do bộ đệm ghi lớn hơn và cấu hình thông lượng đĩa song song.

Tránh thực hiện bất kỳ tập tin I / O hiệu suất cao nào trên các chia sẻ của windows. Có một lượng lớn giao thức sẽ làm chậm đáng kể thông lượng. Ví dụ, nhiều năm trước tôi đã đo một lần chuyển tệp lớn qua mạng WAN nhanh hơn ~ 50% khi sử dụng FTP qua cổ phiếu Windows.

Đừng sử dụng NAS.

Sử dụng cục bộ (OK trong trung hạn với bộ điều khiển RAID tốt) nhưng nếu ngân sách cho phép, hãy chọn SAN tốt. Với may mắn, bạn có thể bắt đầu "chia sẻ" SAN với các hệ thống khác và lấy lại phần lớn số tiền ban đầu.

RAM 4GB phù hợp với hầu hết các hệ thống miễn là nó là Máy chủ SQL chuyên dụng (và nó phải luôn như vậy). Nếu bạn chưa xem xét nó, hãy sử dụng máy chủ SQL và hệ điều hành 64 bit để bạn có thể dễ dàng ném thêm RAM vào mà không phải loay hoay với công cụ PAE / AWE.

Cũng nghĩ về ảo hóa. Bạn sẽ cần một máy chủ thử nghiệm? Một máy chủ dev? Kiểm tra cài đặt SP1? (Không biết xấu hổ cộng với bài trước: sql-server-in-vmware )

Với kích thước cơ sở dữ liệu là 2Gb, không có lý do gì để xem xét SAN. Một NAS sẽ không hoạt động, bạn chỉ nên nghĩ đến việc sử dụng NAS để sao lưu để bạn không lưu trữ các bản sao lưu trên cùng một máy với dữ liệu của bạn và thật dễ dàng để tạo các bản sao từ NAS để lưu trữ ngoài trang web.

Với một cơ sở dữ liệu nhỏ, chỉ cần sử dụng các đĩa cục bộ trong RAID 1 hoặc RAID 10. Nếu cơ sở dữ liệu của bạn vừa với RAM, bạn không phải quá lo lắng về hiệu suất IO. Sử dụng các cửa sổ 64 bit và đặt 8 Gigs vào đó. Điều đó sẽ để lại rất nhiều cho hệ điều hành và cung cấp cho bạn chỗ để phát triển.

Tôi làm việc với các hệ thống sử dụng cả đĩa RAID cục bộ cũng như kết nối SAN. SAN dường như hoạt động tốt hơn ngay cả với trước đây là một máy mới hơn và nhanh hơn. Tôi nghĩ một yếu tố quan trọng là sự sắp xếp đĩa cục bộ là một ổ đĩa duy nhất để SQL chia sẻ I / O đĩa với hệ điều hành và tệp hoán đổi. Điều này có khả năng đóng góp rất nhiều cho lực cản.

Như @spoulson đã đề cập, SAN có thể cung cấp hiệu suất đĩa tốt hơn nhiều. Nó không chỉ là một ổ đĩa riêng biệt mà còn có khả năng trên phần cứng đĩa nhanh hơn nhiều.

Trong trường hợp của chúng tôi, chúng tôi đang sử dụng SAN vì nó cung cấp một vùng lưu trữ tập trung cho các nhóm dịch vụ SQL Server tự động chuyển đổi dự phòng. Khi máy chính bị lỗi, các ổ đĩa windows được gắn trên SAN được kết nối lại với máy sao lưu nóng và máy chủ sẽ hoạt động trở lại khá nhanh. Tất nhiên, điều này đòi hỏi một hệ thống tương tự như VERITAS để quản lý nhóm dịch vụ có thể nằm ngoài phạm vi của bạn.

Một cảnh báo mà chúng tôi đã đấu tranh là việc gán không gian đĩa SAN được xử lý một cách bảo thủ. Bởi vì nó đắt tiền nên họ không thích nó. Với EMC SAN mà chúng tôi sử dụng, bạn không thể lấy lại không gian được chỉ định mà không bỏ toàn bộ LUN. Vì vậy, nếu chúng tôi thấy không gian được phân bổ nhiều hơn mức chúng tôi cần và chúng tôi muốn sử dụng một số không gian đó cho một LUN khác, chúng tôi không thể thu hẹp không gian quá khổ. Chúng tôi phải bỏ nó và phân công lại. Điều này không hoạt động tốt trong môi trường sản xuất.

Như những người khác đã đề xuất, tránh NAS. Bạn cũng có thể đặt các tệp dữ liệu của mình vào ổ cứng ngoài USB.

Đối với cơ sở dữ liệu 2GB nhỏ, SAN sẽ là quá mức cần thiết.

Nói chung, bạn không muốn các ổ SQL của mình được chia sẻ với bất kỳ ứng dụng nào khác. Tương tự như vậy, càng nhiều trục (đĩa) bạn có thể trải rộng các tệp của mình thì càng tốt. Một lần nữa, với một cơ sở dữ liệu nhỏ như bạn mô tả, bạn sẽ có thể phù hợp với mọi thứ bạn cần trong RAM, do đó hiệu suất đĩa sẽ ít hơn một yếu tố.

Điều đó nói rằng, đừng đi và tạo một ổ RAID-10 duy nhất và đặt TẤT CẢ các tệp cơ sở dữ liệu của bạn vào đó. Bạn có thể bắt đầu với một cái gì đó đơn giản như: Dữ liệu - 2x 73GB 15K RPM, Nhật ký RAID1 - 2x 73GB 15K RPM, Sao lưu RAID1 - 7200 RPM lớn hoặc một cặp trong RAID1

Nếu bạn có ngân sách để nâng cấp, hãy thêm một khối riêng biệt khác cho TempDB (nếu bạn thực hiện bất kỳ truy vấn báo cáo / phân tích phức tạp nào) hoặc cung cấp cho ổ đĩa Nhật ký nhiều đĩa hơn và định cấu hình là RAID10 nếu hệ thống của bạn có nhiều giao dịch hơn với khối lượng lớn cập nhật.

Một SAN có thể sẽ có giá gấp 3-4 lần dung lượng lưu trữ được gắn trực tiếp cho số lượng ổ đĩa tương đương. SAN cung cấp nhiều khả năng nâng cao để sao lưu / chụp nhanh, hỗ trợ phân cụm & di chuyển và mở rộng LUN. Nếu những điều này là quan trọng với bạn, nó có thể có giá trị chi phí gia tăng.

Tuyên bố miễn trừ trách nhiệm: Có nhiều vấn đề nghiêm trọng khi lưu trữ tệp cơ sở dữ liệu SQL Server trên NAS. Tất cả các tùy chọn khác đều bằng nhau, chính xác là chọn tùy chọn SAN. Một cuộc thảo luận chi tiết về các vấn đề có liên quan là trong MS KB304261 . Tuy nhiên, chủ đề này đã trở thành tất cả cho các câu hỏi khác liên quan đến SQL Server trên mạng chia sẻ, tôi muốn đăng các tài liệu tham khảo về trạng thái hỗ trợ NAS trong các phiên bản SQL Server.

Hiện tại có một vài người thử nghiệm sử dụng NAS với MS SQL.

Điều này từng bị cấm theo mặc định, tuy nhiên người ta có thể gỡ bỏ hạn chế trong MS SQL 2008 và MS SQL 2005. Vì MS SQL 2008 R2 không có hạn chế đó.

Trong MS SQL 2005 và 2008, khóa là cờ theo dõi cấm sử dụng chia sẻ mạng. Một vấn đề có thể

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Thông tin chi tiết trong bài đăng tháng 9 năm 2010 trong blog MSDN của Varun Dhawan.

Ít nhất về mặt kỹ thuật chạy SQL Server trên NAS là có thể. Sự lựa chọn phụ thuộc vào nhiều yếu tố và không khó để tưởng tượng một tình huống nơi lưu trữ cho cơ sở dữ liệu có sẵn trên NAS.