Ổ đĩa so với điểm Mount?


12

DBA cao cấp trước đó đã thiết lập các điểm gắn kết cho tất cả các ổ đĩa của chúng tôi trên mọi Máy chủ SQL trong toàn công ty. DBA cao cấp mới kinh hoàng bởi các điểm gắn kết muốn thay đổi tiêu chuẩn của chúng tôi (chủ yếu, tôi nghĩ, bởi vì anh ta không có kinh nghiệm với họ).

Dựa trên kết quả của nhiều tìm kiếm trên internet, tôi không thể tìm thấy bất kỳ lý do nào (sau SQL Server 2000) để không sử dụng điểm gắn kết.

Có ai biết về những hạn chế của hệ điều hành Windows liên quan đến chủ đề này không?

  • Gần đây tôi đã nghe tuyên bố "HĐH không nhận ra điểm gắn kết". (Không đúng, dựa trên nghiên cứu của tôi về các phiên bản Windows Server mà chúng tôi sử dụng).

Có bất kỳ lý do dựa trên bằng chứng hoặc dựa trên kinh nghiệm KHÔNG sử dụng điểm gắn kết với SQL Server không?

  • Giả sử rằng việc hết ký tự ổ đĩa không phải là vấn đề đối với chúng tôi.

Theo hiểu biết của tôi thì các điểm gắn kết cực kỳ hữu ích để phân tách khối lượng công việc.

Bất cứ ai cũng có thể xác nhận hoặc bác bỏ sự hiểu biết của tôi rằng các điểm gắn kết thực sự tách biệt / cô lập khối lượng công việc của các loại dữ liệu và tệp nhật ký khác nhau (tệp cơ sở dữ liệu hệ thống, tệp cơ sở dữ liệu người dùng, tempDB) hiệu quả hơn một ổ đĩa cho mỗi tệp dữ liệu, tệp nhật ký và tempdb ?


Lưu trữ vật lý phần lớn được trừu tượng hóa khi người ta sử dụng SAN. Bất kể người ta sử dụng ký tự ổ đĩa hay điểm gắn kết, bạn cần phải làm việc với quản trị viên lưu trữ để cung cấp LUN với các đặc điểm cần thiết. Cả SQL Server và HĐH đều không có kiến ​​thức về cấu hình cơ bản, mặc dù bạn có thể cài đặt các công cụ của nhà cung cấp để cung cấp khả năng hiển thị.
Dan Guzman

Câu trả lời:


13

Nó phụ thuộc vào những gì ở đầu kia của điểm gắn kết. Nếu các gắn kết là tất cả LUNS trải đều trên cùng một ổ đĩa vật lý, thì không có lợi ích. Nếu các LUNS trên tất cả các kênh iSCSI được chia sẻ, chậm, có thể không có lợi ích. Nếu tất cả các LUNS đều dưới 1 bộ điều khiển ... bạn sẽ thấy có bao nhiêu biến đang phát. Không có ai trả lời.

Để xác định cấu hình của các điểm gắn kết, hãy xem Xác định vị trí các điểm gắn kết bằng PowerShell của Boe Prox.


SQL Server không có vấn đề với các điểm gắn kết. Chúng được xác định ở cấp HĐH và SQL Server "không biết 1 " chúng không cùng ổ đĩa với ổ đĩa mà chúng dường như được gắn vào.

Tuy nhiên, một số công cụ giám sát có thể cung cấp cho bạn thông tin xấu dựa trên câu cuối cùng đó.

Ví dụ: nếu bạn có ba điểm gắn kết như

  1. C:\SQLData\SQL_Data nơi lưu trữ tất cả các tệp .MDB của bạn
  2. C:\SQLData\SQL_Logs nơi lưu trữ tất cả các tệp .LDF của bạn
  3. C:\SQLData\SQL_Backups nơi lưu trữ tất cả các tệp sao lưu .BAK và .TRN của bạn

Sau đó, SQL Server sẽ hoạt động mà không có bất kỳ vấn đề. Nhưng nếu bạn chạy một số loại công cụ cảnh báo bạn khi các ổ đĩa có dung lượng thấp, nó có thể kiểm tra C: và không phải các ổ đĩa được gắn bên dưới nó , vì vậy bạn có thể không biết khi nào các điểm gắn kết đó có dung lượng ổ đĩa thấp. Ngoài ra, các truy vấn "thực tiễn tốt nhất" khác nhau sẽ đưa ra các cảnh báo sai cho bạn biết rằng bạn không nên có dữ liệu, nhật ký và sao lưu tất cả trên cùng một đĩa vì SQL Server nghĩ rằng chúng nằm trên cùng một đĩa. Đó là những lá cờ giả, và có thể bỏ qua.

Nhưng về cơ bản, bạn muốn thiết lập một số bước bổ sung trong giám sát máy chủ của mình để đảm bảo ổ C: có đủ dung lượng và mỗi điểm gắn kết cũng vậy.

Thời gian tôi đã sử dụng điểm gắn kết trong SQL Server, đó là vấn đề duy nhất tôi gặp phải: Báo cáo sức khỏe hệ thống SQL Server cung cấp dữ liệu sai về không gian trống có sẵn và các lỗi sai nói rằng bạn không nên có tất cả dữ liệu của mình trên cùng một ổ đĩa. Vì bạn biết đó là những lỗi sai, chúng đủ dễ bỏ qua.


1 Máy chủ SQL có dữ liệu giúp nhận biết điểm gắn kết, nhưng từ quan điểm sử dụng thực tế, không có sự khác biệt trong hành vi. Nó "chỉ hoạt động", tin tưởng HĐH để xử lý các chi tiết cụ thể. Giống như nó tin tưởng HĐH để xử lý các thông số cụ thể cho iSCSI LUN được kết nối dưới dạng các ổ đĩa cục bộ.


2
Không chắc chắn liệu vẫn còn một vấn đề xung quanh cài đặt SQL và ACL xung quanh các điểm gắn kết trên thư mục gốc của ổ đĩa, nhưng có lẽ đáng để đặt chúng vào một thư mục mountpoint chỉ trong trường hợp. Ví dụ: C: \ SQLMountPoints \ SQL_Data, C: \ SQLMountPoints \ SQL_Log
Nic

Thật. Một lần tôi đã làm theo cách này, tôi đã có một thư mục "SQLDATA", sau đó "dữ liệu", "Nhật ký" và "sao lưu" các điểm gắn kết theo đó. Hoặc một cái gì đó để có hiệu lực.
CaM

8

Ngoài CM_Dayton của câu trả lời và Sean Gallardy của câu trả lời , một vấn đề chưa được xác định với Núi điểm có liên quan đến an ninh. Để trích dẫn Nguyên tắc thiết lập quyền SQL trên thư mục Mount Point :

Mặc dù các thư mục gốc của điểm gắn kết có thể trông giống như các thư mục thông thường và được truy cập theo cùng một cách các thư mục được truy cập, chúng không phải là các thư mục thông thường. Kết quả là, khi bạn đặt quyền trên thư mục gốc của điểm gắn kết, các quyền không được kế thừa từ khối lượng cha mẹ của con đường giống như các thư mục thông thường. Trên thực tế, chúng không được thừa kế chút nào. Điều này là do mặc dù có vẻ như khối lượng được gắn kết là con của khối lượng cha mẹ của Wap, nhưng thực tế không phải vậy. Bạn chỉ đơn giản là truy cập vào âm lượng được gắn kết thông qua một đường dẫn từ âm lượng gốc mẹ.

Tóm lại, bạn phải gán quyền cho Mount Folders khác nhau nếu bạn muốn sử dụng thư mục gốc của điểm gắn kết. Thay vì gán quyền như bạn sẽ làm với một thư mục bình thường, bạn phải gán quyền cho âm lượng. Một lần nữa, từ cùng một bài viết (nổi bật là của Microsoft):

Gotchas

Thật không may, vẫn có thể đặt / xem quyền trên thư mục gốc của điểm gắn kết thông qua Windows Explorer, điều này có thể dẫn đến kết quả không mong muốn vì các quyền của thư mục gốc của điểm gắn kết có vẻ hợp lệ và bạn có thể thấy các quyền được kế thừa , tuy nhiên đây không phải là quyền được áp dụng cho âm lượng được gắn.

Hướng dẫn

  1. Bạn không nên đặt bất kỳ tệp nào trực tiếp vào thư mục gốc của điểm gắn kết . Điều này sẽ làm cho việc quản lý quyền đơn giản hơn nhiều, bởi vì xu hướng là luôn kiểm tra các quyền của thư mục, trong trường hợp này là sai lệch. Thay vào đó, hãy tạo một thư mục con trong thư mục gốc của điểm gắn kết và đặt các quyền thích hợp cho thư mục con đó . Vì thư mục con là một thư mục thông thường, các quyền thư mục bạn quan sát và thiết lập thực sự là các quyền được áp dụng. Vì vậy, bằng cách sử dụng ví dụ trước, bạn sẽ muốn tạo một thư mục mới: D: \ FolderForVol3 ** SubfolderXYZ **. Bây giờ, hãy đặt quyền truy cập thư mục của bạn theo thư mục SubfolderXYZ mới như bình thường.
  2. Nếu bạn hoàn toàn phải đặt các mục trực tiếp trong thư mục gốc của điểm gắn kết (Không phải là cách tiếp cận được đề xuất), thì bạn sẽ cần phải đặt quyền truy cập âm lượng, không phải quyền truy cập thư mục. Hãy nhớ lại, đó là bởi vì các quyền của thư mục gốc của điểm gắn kết không phải là các quyền thực sự sẽ được đặt trên ổ đĩa được gắn (vì thư mục gốc của điểm gắn kết không phải là một thư mục thực). Bạn có thể đặt quyền âm lượng như sau:
  3. Nếu bạn đang thêm một thư mục mới để SQL sử dụng, hãy lưu ý các quyền cần thiết để truy cập SQL:

Nếu bạn không muốn lồng mọi thứ trong thư mục con dưới Mount Point như MS khuyến nghị, cách tôi thấy dễ nhất để gán quyền là thông qua cacls.exetiện ích. Hướng dẫn chi tiết cho nó có thể được tìm thấy trong Bạn không thể áp dụng quyền cho thư mục gốc của ổ đĩa hệ thống tệp NTFS trong Windows Server 2003 .

Tôi không nghĩ đó là một vấn đề được giải quyết hoàn toàn. Câu hỏi gần đây về cài đặt SQL Server FCI với các vấn đề về quyền của Mount Point cho thấy nó vẫn có thể xảy ra trên Windows 2012 với SQL Server 2016.

Tùy thuộc vào mức độ bảo mật mà bạn muốn được gán, lệnh có thể khác nhau, nhưng thử nghiệm là chìa khóa thành công, vì vậy hãy làm quen với lệnh trước khi chạy nó với điểm gắn kết trực tiếp vì bạn có thể nhanh chóng bảo mật nếu bạn quên một thứ đơn giản như \Ecờ.


DBA cao cấp trước đó không nhận thức được mối quan tâm bảo mật này (ack!) Và tôi đã không cho đến khi đăng bài này. Tôi sẽ kết hợp một truy vấn CMS để tìm tất cả các tệp db bị ảnh hưởng. Cacls có vẻ như là một tuyến đường tốt (mặc dù tôi sẽ tìm kiếm một cái gì đó dựa trên PoSh). @JohnEisbrener - bạn có gặp vấn đề gì khi đặt ACL trên các tệp db khi bị khóa sử dụng độc quyền không? Nếu vậy, bước tiếp theo là gì?
SQL_Underworld

1
@Query_Underworld, tôi khuyên bạn nên làm bất cứ điều gì với cacls trong cửa sổ bảo trì, trong thời gian đó bạn có thể lấy ví dụ cơ sở dữ liệu ngoại tuyến. Trong khi có lẽ không cần thiết , nó sẽ làm giảm số lượng biến có thể xảy ra.
John Eisbrener

8

Dựa trên kết quả của nhiều tìm kiếm trên internet, tôi không thể tìm thấy bất kỳ lý do nào (sau SQL Server 2000) để không sử dụng điểm gắn kết.

Lý do chính là ai đó đã có trải nghiệm tồi tệ với họ (hoặc ngược lại, không có kinh nghiệm với họ) và đã hoàn toàn loại bỏ họ ... mãi mãi. Điều này còn được gọi là sở thích cá nhân.

Bây giờ, có một số lý do mà bạn không thể sử dụng chúng. Lý do số một tôi có thể nghĩ đến là trình điều khiển hoặc ứng dụng / công cụ của bên thứ 3 (nghĩ rằng trình điều khiển bộ lọc, sao chép đĩa, v.v.) không hỗ trợ nó. Một ví dụ nhanh về điều này là một công cụ sao chép đĩa cấp khối không hỗ trợ bất cứ thứ gì ngoài NTFS, chỉ có kích thước cụm cụ thể và không thể vượt quá 2 TB cho bất kỳ khối lượng cụ thể nào.

Có ai biết về những hạn chế của hệ điều hành Windows liên quan đến chủ đề này không?

Số bạn có thể làm cho nhiều, nhiều điểm gắn kết. Trên thực tế, nhìn chung bạn sẽ gặp sự cố với giao diện thiết bị của mình trước khi bạn đạt bất kỳ giới hạn đáng kể nào bên trong Windows Server (Giả sử bạn không sử dụng phiên bản Windows Server đã trên 17 tuổi ...).

• Gần đây tôi đã nghe tuyên bố "HĐH không nhận ra điểm gắn kết". (Không đúng, dựa trên nghiên cứu của tôi về các phiên bản Windows Server mà chúng tôi sử dụng).

Nếu HĐH không nhận ra điểm gắn kết, thì nó thậm chí sẽ cho phép bạn sử dụng điểm gắn kết như thế nào? Điều đó chỉ vô nghĩa.

Nếu HĐH không nhận ra các điểm gắn kết, tại sao nó lại theo dõi chúng và truy vấn siêu dữ liệu của chúng ? Ngoài ra, xin lưu ý rằng điểm gắn kết là cấu trúc của hệ thống tệp mà HĐH có thể hỗ trợ hoặc không hỗ trợ. Không phải tất cả các hệ thống tệp bạn gặp đều có thể hỗ trợ các điểm gắn kết, tuy nhiên hệ thống tệp phổ biến nhất trong Windows Server là NTFS, trên thực tế không hỗ trợ các điểm gắn kết và nó có một thời gian.

Chỉ cần mang món đồ không đúng sự thật này về nhà hơn nữa; Windows Clustering có một cái gì đó gọi là Cụm chia sẻ chung (CSV) thực sự sử dụng điểm gắn kết cho các tập ... đó là một mục gốc sử dụng công nghệ. Tôi phải nói rằng, bất cứ ai nói với bạn điều này cần phải được giáo dục về vấn đề này.

Có bất kỳ lý do dựa trên bằng chứng hoặc dựa trên kinh nghiệm KHÔNG sử dụng điểm gắn kết với SQL Server không?

Có, luôn có một máy chủ chạy Windows NT 4 ... không sử dụng nó ở đó. Bạn cũng có thể muốn đảm bảo rằng bạn đang chạy một hỗ trợ phiên bản Windows Server và luôn cập nhật các bản cập nhật.

Tuy nhiên, như tôi đã mô tả ở trên, có thể có các mục của bên thứ 3 không được hỗ trợ hoặc không hoạt động đúng với chúng. Tôi muốn nói rằng hãy bỏ nhà cung cấp đó và tìm một nhà cung cấp mới.

Theo hiểu biết của tôi thì các điểm gắn kết cực kỳ hữu ích để phân tách khối lượng công việc.

Điểm gắn kết là vô cùng hữu ích. Có nhiều cách để sử dụng chúng, phổ biến nhất là khắc phục các giới hạn ký tự ổ đĩa (như trong, chỉ có rất nhiều) Windows. Việc sử dụng phổ biến tiếp theo là sử dụng các ổ đĩa có kích thước nhỏ hơn có thể quản lý (nghĩ LUN, đĩa ảo [VMDK, VHDX]) để giúp thoát khỏi khối lượng lớn nguyên khối cực kỳ lớn và hiếm khi quản lý (thực sự trở thành vấn đề để quản lý các ổ đĩa trong phạm vi 10TB như một LUN, đĩa ảo, v.v.) đặc biệt là trên các phiên bản NTFS cũ hơn, nơi triển khai ít hơn mức sử dụng có thể ... ví dụ, trong các phiên bản Windows cũ hơn, kích thước NTFS tối đa là 2TB.

Phân tách khối lượng công việc là một sử dụng tuyệt vời khác. Bạn chắc chắn có thể thấy, có nhiều cách sử dụng và nó phụ thuộc vào trường hợp sử dụng cá nhân của bạn. Cũng có những cách không phù hợp để sử dụng nó ... chẳng hạn như đưa ra tuyên bố về chăn rằng mọi thứ cần phải là điểm gắn kết. Đó chỉ là chi phí hành chính điên rồ vào thời điểm đó.


3

Mountpoint là cách để đi đến các máy chủ có ứng dụng chia sẻ hoặc cắt dữ liệu trên nhiều khối lượng DZ thông thường.

Ví dụ: bạn có thể cài đặt tất cả một dữ liệu ứng dụng, tệp nhật ký và tệp tạm thời trên e:ổ đĩa chẳng hạn. E:/MP_1có thể có tệp dữ liệu cho Doanh nghiệp A, E:/MP_2có thể có tệp nhật ký E:/mp_3có thể có tệp tạm thời cho Doanh nghiệp A, v.v. Sau đó, bạn có Business B trên các điểm gắn kết trên F:Drive. Mỗi điểm gắn kết có không gian riêng.

HĐH hoàn toàn không có vấn đề gì với MP. Các cụm và Luôn bật không có vấn đề với MP. Tôi đã làm việc cho một ngân hàng rất nổi tiếng có phần lớn Máy chủ SQL của họ được cài đặt trên MP. Một khi DBA sử dụng chúng và hiểu các khái niệm, nó sẽ thúc đẩy họ đến các giải pháp dễ dàng hơn trong các cửa hàng cần nó.

Nó đã được đề cập không cài đặt bất cứ điều gì trên root MP. Đúng vậy Không có gì trên root MP giống như bạn sẽ không cài đặt bất cứ thứ gì vào root của D làm ví dụ.

Các giải pháp kiểm tra và giám sát như Foglight, Guardiam, EMS và PBM cũng không có vấn đề gì với các điểm gắn kết.

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.