Date: พฤษภาคม 8, 2019
ป้ายกำกับ:SQL Server ใน Azure, ข้อควรพิจารณาในการเก็บรักษา
ข้อควรพิจารณาในการเก็บข้อมูลสำหรับการเรียกใช้ SQL Server ใน Azure
การปรับใช้ SQL Server ใน Azure หรือแพลตฟอร์มคลาวด์ใด ๆ แทนที่จะเป็นเพียงแค่การจัดสรรพื้นที่เก็บข้อมูลเช่นเดียวกับที่คุณทำสำหรับการปรับใช้งานในสถานที่ของคุณเป็นเวลาหลายปีการพิจารณาพื้นที่เก็บข้อมูลใน Azure ไม่เหมือนกับที่เก็บข้อมูลที่คุณมีสิทธิ์เข้าถึงในสถานที่ "แนวทางปฏิบัติที่ดีที่สุด" แบบดั้งเดิมบางอย่างอาจทำให้คุณต้องเสียเงินเพิ่มและให้ประสิทธิภาพที่ดีที่สุด ถึงกระนั้นก็ตามในขณะที่ไม่ได้ให้สิทธิประโยชน์ใด ๆ แก่คุณ สิ่งที่ฉันกำลังจะพูดคุยส่วนใหญ่ยังอธิบายไว้ในแนวทางปฏิบัติสำหรับ Azure ในเครื่องเสมือนเซิร์ฟเวอร์ SQL
ประเภทของดิสก์
ฉันไม่ได้มาที่นี่เพื่อบอกคุณว่าคุณต้องใช้ UltraSSD, ที่เก็บข้อมูลพรีเมียมหรือดิสก์ประเภทอื่น คุณเพียงแค่ต้องระวังว่าคุณมีตัวเลือกและสิ่งที่ดิสก์แต่ละชนิดนำมาไว้ในตาราง แน่นอนเช่นเดียวกับสิ่งอื่นใดในคลาวด์คุณจะได้รับเงินมากขึ้นพลังยิ่งขึ้นความเร็วปริมาณงานและอื่น ๆ ที่มากขึ้น เคล็ดลับคือการค้นหาการกำหนดค่าที่เหมาะสมที่สุดที่เหมาะสมกับข้อควรพิจารณาในการจัดเก็บของคุณเพื่อให้คุณใช้จ่ายเพียงพอที่จะบรรลุผลลัพธ์ที่ต้องการ
ขนาดมีความสำคัญ
เช่นเดียวกับหลายสิ่งในคลาวด์สเป็คบางอย่างเชื่อมติดกัน สำหรับเซิร์ฟเวอร์หากคุณต้องการ RAM เพิ่มคุณมักจะได้รับ CPU มากขึ้นแม้ว่าคุณจะไม่ต้องการ CPU มากขึ้น สำหรับการจัดเก็บข้อมูล IOPS ปริมาณงานและขนาดจะเชื่อมโยงกัน หากคุณต้องการ IOPS เพิ่มขึ้นคุณต้องมีดิสก์ที่ใหญ่กว่า หากคุณต้องการพื้นที่เพิ่มขึ้นคุณจะได้รับ IOPS เพิ่มขึ้นด้วย แน่นอนว่าคุณสามารถข้ามไปมาระหว่างคลาสหน่วยเก็บข้อมูลเพื่อหลีกเลี่ยงสิ่งนั้นได้ในระดับหนึ่ง แต่มันก็ยังคงเป็นความจริงที่ว่าถ้าคุณต้องการ IOPS มากขึ้นคุณจะมีพื้นที่มากขึ้นสำหรับประเภทหน่วยความจำประเภทต่าง ๆ ขนาดของอินสแตนซ์ของเครื่องเสมือนก็มีความสำคัญเช่นกัน ไม่ว่าคุณจะใช้การตั้งค่าการจัดเก็บแบบใดในที่สุดปริมาณงานโดยรวมจะถูก จำกัด ที่ขนาดใดก็ตามที่อนุญาต ดังนั้นอีกครั้งคุณอาจต้องจ่าย RAM และ CPU มากกว่าที่คุณต้องการเพียงเพื่อให้ได้ประสิทธิภาพการจัดเก็บที่คุณต้องการ ตรวจสอบให้แน่ใจว่าคุณเข้าใจขนาดอินสแตนซ์ของคุณที่สามารถรองรับได้ในแง่ของปริมาณ IOPS สูงสุดและเมกะบิตต่อวินาที หลายครั้งที่อินสแตนซ์ขนาดกลายเป็นคอขวดในปัญหาประสิทธิภาพการจัดเก็บข้อมูลที่รับรู้ใน Azure
ใช้ Raid 0
RAID 0 นั้นเป็นทางเลือกที่ 3 ของการจัดเก็บข้อมูล แม้ว่าจะให้การผสมผสานที่ดีที่สุดของประสิทธิภาพและการใช้ประโยชน์พื้นที่เก็บข้อมูลของตัวเลือก RAID ใด ๆ แต่ก็มีความเสี่ยงที่จะเกิดความล้มเหลวอย่างรุนแรง ชุดสตริปทั้งหมดล้มเหลวเมื่อเพียงดิสก์เดียวในชุด RAID 0 สตริปล้มเหลว ด้วยเหตุนี้ RAID 0 แบบดั้งเดิมจึงถูกใช้ในสถานการณ์ที่การสูญเสียข้อมูลเป็นที่ยอมรับและต้องการประสิทธิภาพสูง อย่างไรก็ตามในซอฟต์แวร์ Azure RAID 0 เป็นที่ต้องการและแนะนำให้ใช้ในหลาย ๆ สถานการณ์ เราจะไปด้วย RAID 0 ใน Azure ได้อย่างไร คำตอบนั้นง่าย แต่ละดิสก์ที่คุณนำเสนอให้กับอินสแตนซ์ของเครื่องเสมือน Azure มีความซ้ำซ้อนอยู่สามส่วนในแบ็กเอนด์ หมายความว่าคุณจะต้องมีความล้มเหลวหลายครั้งก่อนที่คุณจะสูญเสียชุดแถบ ด้วยการใช้ RAID 0 คุณสามารถรวมหลายดิสก์ได้ ประสิทธิภาพโดยรวมของชุดสตริปรวมจะเพิ่มขึ้น 100% สำหรับแต่ละดิสก์เพิ่มเติมที่คุณเพิ่มไปยังชุดสตริป ตัวอย่างเช่นคุณมีความต้องการ 10,000 IOPS คุณอาจคิดว่าคุณต้องการ UltraSSD เนื่องจาก Premium Storage สูงสุดถึง 7,500 IOPS ด้วย P50 อย่างไรก็ตามด้วยการใส่ P50 สองตัวใน RAID 0 ตอนนี้คุณมีศักยภาพที่จะบรรลุถึง 15,000 IOPS นั่นคือสมมติว่าคุณกำลังเรียกใช้ Standard_F16s_v2 หรือขนาดอินสแตนซ์ขนาดใหญ่ที่คล้ายกันซึ่งสนับสนุน IOPS จำนวนมาก ใน Windows 2012 และหลังจากนั้น RAID 0 สามารถทำได้โดยการสร้าง Simple Storage Space ใน Windows Server 2008 R2 คุณสามารถใช้ Dynamic Disks เพื่อสร้าง RAID 0 Striped Volume เพียงแค่คำเตือน หากคุณกำลังจะใช้พื้นที่เก็บข้อมูลภายในเครื่องและกำหนดค่ากลุ่มความพร้อมใช้งานหรือ SANless Failover Cluster Instance กับ DataKeeper วิธีที่ดีที่สุดคือกำหนดค่าที่เก็บข้อมูลของคุณก่อนสร้างคลัสเตอร์ เพียงเตือนความจำ คุณมีเวลาอีกประมาณสองเดือนในการย้ายอินสแตนซ์ SQL Server 2008 R2 ของคุณไปยัง Azure ลองดูโพสต์ของฉันเกี่ยวกับวิธีปรับใช้ SQL Server 2008 R2 FCI บน Azure เพื่อให้แน่ใจว่ามีความพร้อมใช้งานสูง
ไม่ต้องแยกไฟล์บันทึกและข้อมูล
ตามปกติไฟล์บันทึกและข้อมูลจะอยู่ในดิสก์ที่มีอยู่จริง ไฟล์บันทึกมักจะมีกิจกรรมการเขียนจำนวนมากและไฟล์ข้อมูลมักจะมีกิจกรรมการอ่านมากกว่า ดังนั้นบางครั้งการจัดเก็บจะได้รับการปรับให้เหมาะสมตามลักษณะเหล่านั้น มันเป็นที่พึงปรารถนาที่จะเก็บไฟล์บันทึกและข้อมูลในดิสก์ที่แตกต่างกันเพื่อการกู้คืน หากคุณควรทำอย่างใดอย่างหนึ่งโดยใช้กลยุทธ์การสำรองข้อมูลที่เหมาะสมคุณสามารถกู้คืนฐานข้อมูลของคุณโดยไม่สูญเสียข้อมูล ด้วยที่จัดเก็บข้อมูลบนคลาวด์โอกาสที่จะสูญเสียเพียงโวลุ่มเดียวนั้นต่ำมาก ตอนนี้คุณกำลังคิดถึงข้อควรพิจารณาในการจัดเก็บ หากคุณสูญเสียที่เก็บข้อมูลเป็นไปได้ว่ามันอาจเป็นไปได้ที่คลัสเตอร์จัดเก็บข้อมูลทั้งหมดของคุณ ดังนั้นในขณะที่อาจรู้สึกถูกต้องที่จะใส่บันทึกลงใน E: บันทึกและข้อมูลใน F: data คุณกำลังก่อความเสียหายให้ตัวเองจริงๆ ตัวอย่างเช่นคุณจัดเตรียม P20 สำหรับบันทึกและ P20 สำหรับข้อมูล แต่ละเล่มจะมีขนาด 512 GiB และต่อยอดที่ 2,300 IOPS แค่คิดว่าคุณอาจไม่ต้องการขนาดไฟล์บันทึกทั้งหมด แต่มันอาจไม่ทำให้คุณมีพื้นที่มากพอที่จะเติบโตสำหรับไฟล์ข้อมูลของคุณ ในที่สุดจะต้องย้ายไปที่ P30 แพงกว่าเพียงเพื่อเพิ่มพื้นที่ มันจะดีกว่าหรือเปล่าที่จะรวมเอาสองวอลลุ่มเหล่านี้เข้าด้วยกันในปริมาณ 1 TB ขนาดใหญ่ที่รองรับ 4,600 IOPS ด้วยการทำเช่นนั้นทั้งไฟล์บันทึกและข้อมูลสามารถใช้ประโยชน์จาก IOPS ที่เพิ่มขึ้น และคุณเพียงเพิ่มประสิทธิภาพการใช้พื้นที่เก็บข้อมูลของคุณและลดต้นทุนการจัดเก็บข้อมูลบนคลาวด์ด้วยการย้ายการย้ายไปยังดิสก์ P30 สำหรับไฟล์ข้อมูลของคุณ เช่นเดียวกับที่เก็บไฟล์จริงและกลุ่มไฟล์ คิดถึงสิ่งที่คุณกำลังทำจริงๆ ไม่ว่าจะยังคงสมเหตุสมผลเมื่อคุณย้ายไปที่คลาวด์ สิ่งที่สมเหตุสมผลอาจเป็นเรื่องที่เข้าใจได้ง่ายในสิ่งที่คุณเคยทำในอดีต เมื่อมีข้อสงสัยให้ปฏิบัติตามกฎ KISS, Keep It Simple Stupid! ความสวยงามของคลาวด์คือคุณสามารถเพิ่มพื้นที่เก็บข้อมูลได้มากขึ้นเพิ่มขนาดอินสแตนซ์หรือทำทุกอย่างเพื่อเพิ่มประสิทธิภาพเทียบกับราคา
จะทำอย่างไรกับ TempDB
ใช้ SSD ท้องถิ่นหรือที่รู้จักในชื่อไดรฟ์ D: ไดรฟ์ D จะเป็นตำแหน่งที่ดีที่สุดสำหรับ tempdb ของคุณ เนื่องจากเป็นไดรฟ์ในระบบข้อมูลจึงถูกพิจารณาว่าเป็น "ชั่วคราว" ความหมายอาจหายไปหากย้ายเซิร์ฟเวอร์รีบูตเครื่อง ฯลฯ ไม่เป็นไร. Tempdb จะถูกสร้างขึ้นใหม่ทุกครั้งที่ SQL เริ่มทำงาน SSD ท้องถิ่นจะเร็วและมีเวลาหน่วงต่ำ แต่เนื่องจากเป็นโลคัลการอ่านและเขียนจึงไม่ส่งผลต่อขีด จำกัด IOPS หน่วยเก็บโดยรวมของขนาดอินสแตนซ์ อย่างมีประสิทธิภาพมันฟรี IOPS! ทำไมไม่ใช้ประโยชน์จาก? หากคุณกำลังสร้าง FCless ของ SANless SQL Server ด้วย SIOS DataKeeper อย่าลืมสร้างไดรฟ์ข้อมูลทรัพยากรที่ไม่ใช่มิร์เรอร์ของไดรฟ์ D วิธีนี้คุณไม่จำเป็นต้องทำซ้ำ TempDB
คะแนนติดกลายเป็นล้าสมัย
โดยทั่วไป Mount Points จะใช้ในการกำหนดค่า FCI ของเซิร์ฟเวอร์ SQL เมื่อมีการติดตั้ง SQL Server หลายอินสแตนซ์บน Windows Cluster เดียวกัน สิ่งนี้ช่วยลดต้นทุนโดยรวมของสิทธิ์การใช้งาน SQL Server สามารถช่วยประหยัดค่าใช้จ่ายด้วยการผลักดันการใช้เซิร์ฟเวอร์ให้สูงขึ้น ดังที่เรากล่าวถึงในอดีตโดยทั่วไปอาจมีไดรฟ์ห้าตัวหรือมากกว่าที่เกี่ยวข้องกับ SQL Server แต่ละอินสแตนซ์ หากไดรฟ์แต่ละตัวเหล่านั้นต้องใช้ตัวอักษรไดรฟ์คุณจะใช้ตัวอักษรหมดในอินสแตนซ์ประมาณสามถึงสี่ตัว ดังนั้นแทนที่จะให้ตัวอักษรแต่ละไดรฟ์จุดเมาท์ถูกใช้เพื่อให้แต่ละอินสแตนซ์สามารถรับบริการด้วยตัวอักษรไดรฟ์เดียวไดรฟ์ราก ไดรฟ์รากมีจุดเมานท์ที่แมปไปยังดิสก์ทางกายภาพที่ไม่มีตัวอักษรของไดรฟ์ อย่างไรก็ตามตามที่เราได้กล่าวถึงข้างต้นแนวคิดของการใช้ดิสก์จำนวนมากแต่ละอันไม่ได้ทำให้เกิดความรู้สึกในคลาวด์ ดังนั้นจุดที่เมาท์จะล้าสมัยในก้อนเมฆ ให้สร้างแถบ RAID 0 แทนเราดังที่อธิบายไว้ แต่ละอินสแตนซ์ของคลัสเตอร์ SQL Server จะมีปริมาณของตัวเองที่ปรับให้เหมาะสมสำหรับพื้นที่ประสิทธิภาพและต้นทุน วิธีนี้จะช่วยแก้ปัญหาการไม่มีตัวอักษรไดรฟ์ นอกจากนี้ยังช่วยให้คุณใช้พื้นที่จัดเก็บและประสิทธิภาพได้ดีขึ้นในขณะที่ลดค่าใช้จ่ายในการจัดเก็บบนคลาวด์ของคุณ
สรุปผลการวิจัย
โพสต์นี้มีความหมายว่าเป็นจุดกระโดดไม่ใช่แนวทางที่ชัดเจน ประเด็นหลักของการโพสต์คือให้คุณคิดต่างกันเกี่ยวกับข้อควรพิจารณาเกี่ยวกับคลาวด์และสตอเรจเนื่องจากเกี่ยวข้องกับการใช้ SQL Server ใน Azure อย่าใช้สิ่งที่คุณทำในสถานที่และสร้างใหม่ในคลาวด์ ซึ่งจะส่งผลให้ประสิทธิภาพการทำงานที่ดีที่สุดและค่าจัดเก็บข้อมูลขนาดใหญ่กว่าที่จำเป็น ทำซ้ำโดยได้รับอนุญาตจาก Clusteringformeremortals.com