SQL Server Files Local หรือ NAS หรือ SAN หรือไม่

ฉันต้องติดตั้งเซิร์ฟเวอร์ใหม่ด้วย SQL Server 2008, คุณแนะนำอะไร, เซิร์ฟเวอร์หนึ่งตัวที่มี Raid 10 หรือไฟล์ใน NAS?

ฉันควรใช้ iSCSI เกี่ยวกับอะไร

แล้ว SAN ล่ะ?

เซิร์ฟเวอร์มี RAM 4Gb และไฟล์ฐานข้อมูลนั้นมีขนาดประมาณ 2GB

เพื่อให้ชัดเจนในวันนี้เซิร์ฟเวอร์ไม่มี RAID ฉันต้องใช้กลยุทธ์บางอย่างดังนั้นหากมีสิ่งใดเกิดขึ้นฉันสามารถทำให้ไฟล์ของฉันปลอดภัยได้ดังนั้นฉันควรเลือก Local Files, NAS, SAN อย่างไร ตัวเลือกใดมีประสิทธิภาพสูงสุดความปลอดภัยมากขึ้นคืออะไร

NAS

ไม่ใช่ NAS สำหรับ SQL Server อย่างแน่นอน SMB / CIFS ไม่มีการสนับสนุนที่เพียงพอสำหรับการล็อกไฟล์เพื่อสนับสนุน DBMS (อย่างน้อยก็ไม่กี่ปีที่ผ่านมาระหว่างปี 2002-2003) โปรดทราบว่า NFS ทำและคุณสามารถทำสิ่งนี้กับ Oracle บนเซิร์ฟเวอร์ NFS อย่างไรก็ตาม SQL Server บน CIFS ที่ใช้ร่วมกันไม่น่าเชื่อถือเนื่องจากข้อ จำกัด ของโพรโทคอล อาจไม่อนุญาตให้คุณใส่ไฟล์ลงใน CIFS ที่เมาท์แชร์

SAN

สิ่งนี้เป็นสิ่งที่ดีสำหรับแอปพลิเคชันการทำธุรกรรมเนื่องจากแคชบนตัวควบคุม RAID สามารถดูดซับชุดการทำงานที่มีขนาดค่อนข้างใหญ่ โดยทั่วไปแล้วคอนโทรลเลอร์ SAN RAID จะสนับสนุนแคชมากกว่าโฮสต์คอนโทรลเลอร์ RAID ที่ใช้โฮสต์โดยเฉพาะอย่างยิ่งในชุดระดับ high-end ที่คอนโทรลเลอร์ RAID อาจเป็นกล่องมัลติโปรเซสเซอร์ซึ่งมีประสิทธิภาพเทียบเท่ากับเซิร์ฟเวอร์

SAN ที่มีตัวควบคุมแบบคู่ยังมีสถาปัตยกรรมที่ไม่มีความล้มเหลวเพียงจุดเดียวและมีตัวเลือกมากมายสำหรับการแบ็คอัพที่ร้อนแรง สิ่งนี้ทำให้พวกเขาได้รับชัยชนะจากความสามารถในการจัดการและความน่าเชื่อถือ อย่างไรก็ตามพวกเขามีราคาแพงและถูก จำกัด สำหรับการสตรีมข้อมูลปริมาณแม้ว่าหลังไม่น่าจะเป็นปัญหาในระบบการทำธุรกรรม

สำหรับระบบปฏิบัติการ SAN มักเป็นตัวเลือกที่ดีที่สุดหากมี พวกเขายังสามารถใช้ร่วมกันระหว่างเซิร์ฟเวอร์หลายเครื่องที่ใช้ระบบเสียงต่ำกลาง อย่างไรก็ตามพวกเขามาพร้อมกับป้ายราคาที่ทำให้ขอบเขตค่อนข้างต่ำในระบบที่เล็กที่สุดที่เทคโนโลยีสามารถใช้ได้

แนบโดยตรง

ในบางกรณีการแนบที่เก็บข้อมูลโดยตรงนั้นดีที่สุด ความเป็นไปได้อย่างหนึ่งคือแอพพลิเคชั่นสตรีมมิ่งที่ จำกัด แบนด์วิดท์ซึ่งการเชื่อมต่อ Fibre Channel จำนวน จำกัด จะ จำกัด แบนด์วิดท์ที่มีให้เหลือน้อยกว่าที่อาจเป็นไปได้ด้วยคอนโทรลเลอร์ SAS ระดับสูง อย่างไรก็ตามสิ่งเหล่านี้น่าจะเป็นแอพพลิเคชั่นที่ค่อนข้างพิเศษเช่นคลังข้อมูลขนาดใหญ่ซึ่งสถาปัตยกรรมแบบไม่มีอะไรที่แชร์กันอาจให้ปริมาณงานที่ดีที่สุด

ในความเป็นจริงการแนบหน่วยความจำโดยตรงมักจะดีกว่า SAN สำหรับระบบคลังข้อมูลด้วยเหตุผลหลายประการ:

• คลังข้อมูลใส่ spikes โหลดชั่วคราวขนาดใหญ่บนระบบย่อยของดิสก์ สิ่งนี้ทำให้พวกเขาต่อต้านโซเชียลบน SAN ได้มากเนื่องจากพวกมันสามารถส่งผลกระทบต่อประสิทธิภาพของระบบอื่น ๆ ของ SAN

• คอขวดสตรีมดังกล่าวข้างต้น

• ที่เก็บข้อมูลแนบโดยตรงนั้นค่อนข้างถูกกว่าที่เก็บข้อมูล SAN มาก

ตลาดอื่นสำหรับที่เก็บข้อมูลแบบต่อพ่วงโดยตรงคือเมื่อคุณขายสินค้าในตลาดที่จะไม่จ่ายเงินให้กับ SAN มากพอ นี่เป็นเรื่องจริงของแอปพลิเคชันที่ขายให้กับลูกค้า SMB สำหรับระบบขาย ณ จุดขายหรือระบบการจัดการฝึกหัดที่จะมีผู้ใช้หกคน SAN อาจมีราคาแพงเกินไป ในสถานการณ์ประเภทนี้เซิร์ฟเวอร์ทาวเวอร์แบบสแตนด์อะโลนขนาดเล็กที่มีดิสก์ภายในบางตัวเป็นโซลูชันที่เหมาะสมกว่า

Local หรือ SAN เป็นวิธีเดียวในการรักษาประสิทธิภาพ ในบางกรณี SAN สามารถเร็วกว่าดิสก์ในเครื่องเนื่องจากแคชการเขียนที่ใหญ่กว่าและการกำหนดค่าทรูพุตของดิสก์แบบขนาน

หลีกเลี่ยงการทำ I / O ไฟล์ประสิทธิภาพสูงผ่าน windows share มีโอเวอร์เฮดของโปรโตคอลจำนวนมากซึ่งจะทำให้ปริมาณงานช้าลงอย่างมาก ตัวอย่างเช่นปีที่แล้วฉันวัดว่าการถ่ายโอนไฟล์ขนาดใหญ่ผ่าน WAN นั้นเร็วกว่า ~ 50% โดยใช้ FTP ผ่าน Windows ที่แชร์

อย่าใช้ NAS

ใช้ local (OK สำหรับคำกลางด้วย RAID controller ที่ดี) แต่ถ้างบประมาณอนุญาตให้ไปหา SAN ที่เหมาะสม ด้วยโชคคุณสามารถเริ่ม "แบ่งปัน" SAN กับระบบอื่น ๆ และเรียกคืนค่าใช้จ่ายเริ่มต้นได้มาก

4GB RAM นั้นใช้ได้สำหรับระบบส่วนใหญ่ตราบใดที่มันเป็น SQL Server โดยเฉพาะ (และควรจะเป็นเสมอ) หากคุณยังไม่ได้พิจารณาให้ใช้ 64 บิตระบบปฏิบัติการและเซิร์ฟเวอร์ SQL เพื่อให้คุณสามารถโยน RAM ได้อย่างง่ายดาย

คิดเกี่ยวกับระบบเสมือนจริงด้วย คุณจะต้องมีเซิร์ฟเวอร์ทดสอบหรือไม่ เซิร์ฟเวอร์ dev หรือไม่ ทดสอบการติดตั้ง SP1 หรือไม่ (ไม่มีเครื่องหมายบวกสำหรับโพสต์ก่อนหน้านี้: sql-server-in-vmware )

ด้วยขนาดฐานข้อมูล 2Gb จึงไม่มีเหตุผลที่จะต้องพิจารณา SAN NAS จะไม่ทำงานคุณควรคิดถึงการใช้ NAS เพื่อสำรองข้อมูลดังนั้นคุณจึงไม่ได้จัดเก็บข้อมูลสำรองไว้ในเครื่องเดียวกับข้อมูลของคุณและเป็นเรื่องง่ายที่จะทำสำเนาจาก NAS สำหรับการจัดเก็บนอกสถานที่

ด้วยฐานข้อมูลขนาดเล็กเพียงใช้ดิสก์ในเครื่องใน RAID 1 หรือ RAID 10 หากฐานข้อมูลของคุณเหมาะกับ RAM คุณไม่ต้องกังวลเกี่ยวกับประสิทธิภาพของ IO ใช้ windows 64 บิตและใส่ 8 Gigs ลงไป สิ่งนี้จะทำให้ระบบปฏิบัติการของคุณมีพื้นที่เหลือเฟือ

ฉันทำงานกับระบบที่ใช้ดิสก์ RAID ภายในเครื่องรวมถึงไฟเบอร์เชื่อมต่อ SAN SAN ดูเหมือนจะทำงานได้ดีขึ้นแม้ว่าในอดีตจะเป็นเครื่องที่ใหม่กว่าและเร็วกว่า ฉันคิดว่าปัจจัยสำคัญคือการจัดเรียงดิสก์ภายในเครื่องเป็นไดรฟ์เดียวดังนั้น SQL จึงแบ่งปันดิสก์ I / O กับระบบปฏิบัติการและสลับไฟล์ สิ่งนี้น่าจะมีส่วนอย่างมากต่อการลาก

ดังที่ @ spoulson กล่าวถึง SAN สามารถมอบประสิทธิภาพการทำงานของดิสก์ที่ดีกว่า ไม่เพียง แต่เป็นไดรฟ์ที่แยกจากกัน แต่ยังมีโอกาสเกิดปัญหากับฮาร์ดแวร์ดิสก์ที่เร็วกว่าอีกมาก

ในกรณีของเราเราใช้ SAN เนื่องจากเป็นพื้นที่จัดเก็บข้อมูลส่วนกลางสำหรับกลุ่มบริการของ VERITAS SQL Server อัตโนมัติ เมื่อเครื่องหลักล้มเหลว windows ไดรฟ์ที่ติดตั้งบน SAN จะถูกประกอบเข้ากับเครื่องสำรองข้อมูลที่ร้อนและเซิร์ฟเวอร์จะกลับมาทำงานได้อย่างรวดเร็ว แน่นอนว่าสิ่งนี้ต้องการระบบที่คล้ายกับ VERITAS สำหรับการจัดการกลุ่มบริการซึ่งอาจอยู่นอกขอบเขตของคุณ

ข้อแม้หนึ่งที่เราต่อสู้คือการกำหนดพื้นที่ดิสก์ SAN ได้รับการจัดการอย่างระมัดระวัง เนื่องจากมีราคาแพงพวกเขาไม่ได้ตั้งใจทำอาหาร ด้วย EMC SAN ที่เราใช้คุณไม่สามารถเรียกคืนพื้นที่ที่กำหนดโดยไม่ทิ้ง LUN ทั้งหมด ดังนั้นหากเราพบว่าพื้นที่ที่จัดสรรนั้นมากกว่าที่เราต้องการและเราต้องการใช้พื้นที่นั้นสำหรับ LUN อื่นเราไม่สามารถย่อขนาดที่ใหญ่เกินไปได้ เราต้องวางมันและกำหนดใหม่ สิ่งนี้ใช้งานไม่ได้ในสภาพแวดล้อมการผลิต

ตามที่คนอื่นแนะนำให้หลีกเลี่ยง NAS คุณอาจวางไฟล์ข้อมูลไว้ในฮาร์ดไดรฟ์ USB ภายนอก

สำหรับฐานข้อมูลขนาดเล็ก 2GB SAN จะทำงานหนักเกินไป

โดยทั่วไปคุณไม่ต้องการให้ไดรฟ์ SQL ของคุณแบ่งปันกับแอปพลิเคชันอื่น ยิ่งแกนหมุน (ดิสก์) มากเท่าไหร่คุณก็ยิ่งสามารถกระจายไฟล์ได้ทั่วถึงมากขึ้นเท่านั้น อีกครั้งด้วยฐานข้อมูลขนาดเล็กอย่างที่คุณอธิบายคุณจะสามารถใส่ทุกอย่างที่คุณต้องการใน RAM ได้ดังนั้นประสิทธิภาพของดิสก์จะน้อยลง

ที่กล่าวว่าอย่าไปและสร้างโวลุ่ม RAID-10 เดียวและใส่ไฟล์ฐานข้อมูลทั้งหมดของคุณไว้ คุณสามารถเริ่มด้วยสิ่งที่ง่าย ๆ เช่น: ข้อมูล - 2x 73GB 15K RPM, RAID1 Logs - 2x 73GB 15K RPM, RAID1 สำรอง - ขนาดใหญ่ 7200 RPM เดี่ยวหรือคู่ใน RAID1

หากคุณมีงบประมาณในการอัพเกรดเพิ่มไดรฟ์ข้อมูลแยกต่างหากสำหรับ TempDB (ถ้าคุณทำการรายงานที่ซับซ้อน / การวิเคราะห์เชิงวิเคราะห์) หรือให้ดิสก์บันทึกปริมาณมากขึ้น & กำหนดเป็น RAID10 หากคุณเป็นระบบที่มีธุรกรรมมากขึ้น ของการอัปเดต

มีแนวโน้มว่า SAN จะมีราคาประมาณ 3-4 เท่าของที่เก็บข้อมูลแบบต่อพ่วงโดยตรงสำหรับไดรฟ์จำนวนเท่ากัน SAN มีความสามารถขั้นสูงมากมายสำหรับการสำรอง / สแนปชอตการทำคลัสเตอร์สนับสนุน & การโยกย้ายและการขยาย LUN หากสิ่งเหล่านี้มีความสำคัญต่อคุณอาจมีค่าใช้จ่ายเพิ่มเติม

Disclaimer:มีปัญหาร้ายแรงหลายประการในการจัดเก็บไฟล์ฐานข้อมูล SQL Server บน NAS ตัวเลือกอื่น ๆ ทั้งหมดเท่ากันมันถูกต้องเพื่อเลือกตัวเลือก SAN การอภิปรายรายละเอียดของประเด็นที่เกี่ยวข้องที่อยู่ในMS KB304261 แต่กระทู้นี้ได้กลายเป็นที่จับสำหรับคำถามอื่น ๆ ที่เกี่ยวข้องกับ SQL Server บนเครือข่ายที่ใช้ร่วมกันฉันควรโพสต์การอ้างอิงถึงสถานะของการสนับสนุน NAS ใน SQL Server รุ่น

มีคนไม่กี่คนที่ทดลองใช้ NAS กับ MS SQL

สิ่งนี้เคยเป็นสิ่งต้องห้ามโดยค่าเริ่มต้น แต่อย่างใดอย่างหนึ่งสามารถยกข้อ จำกัด ใน MS SQL 2008 และ MS SQL 2005 ตั้งแต่ MS SQL 2008 R2 ไม่มีข้อ จำกัด ดังกล่าว

ใน MS SQL 2005 และ 2008 คีย์คือค่าสถานะการสืบค้นกลับที่ห้ามการใช้เครือข่ายที่ใช้ร่วมกัน หนึ่งสามารถออก

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

รายละเอียดเพิ่มเติมใน โพสต์กันยายน 2010ในบล็อก MSDN ของ Varun Dhawan

อย่างน้อยทางเทคนิคที่ใช้ SQL Server บน NAS เป็นไปได้ ตัวเลือกขึ้นอยู่กับปัจจัยหลายอย่างและไม่ยากที่จะจินตนาการถึงสถานการณ์ที่ที่เก็บข้อมูลสำหรับฐานข้อมูลพร้อมใช้งานบน NAS