วันอาทิตย์ที่ 25 พฤศจิกายน พ.ศ. 2555

LUN คือ

A logical unit number (LUN) is a unique identifier used to designate individual or collections of hard disk devices for address by a protocol associated with a SCSI, iSCSI, Fibre Channel (FC) or similar interface. LUNs are central to the management of block storage arrays shared over a storage area network (SAN).

The term LUN dates back to the early days of SCSI when each device was identified by a logical number, up to eight in those days. Now servers with a dozen or more LUNs are common and it's getting less common for them to be connected to a conventional internal SCSI disk array. However, the basic element of storage for the server is still referred to as the LUN.

Each LUN identifies a specific logical unit, which may be a part of a hard disk drive, an entire hard disk or several hard disks in a storage device. So a LUN could reference an entireRAID set, a single disk or partition, or multiple hard disks or partitions. In any case, the logical unit is treated as if it is a single device and is identified by the LUN.

Here's how LUNs work with SCSI:
A SCSI (Small System Computer Interface) is a parallel interface that can have up to eight devices all attached through a single cable; the cable and the host (computer) adapter make up the SCSI bus. The bus allows the interchange of information between devices independently of the host. In the SCSI program, each device is assigned a unique number, which is either a number between 0 and 7 for an 8-bit (narrow) bus, or between 8 and 16 for a 16-bit (wide) bus. The devices that request input/output (I/O) operations are initiators and the devices that perform these operations are targets. Each target has the capacity to connect up to eight additional devices through its own controller; these devices are the logical units, each of which is assigned a unique number for identification to the SCSI controller for command processing.

In LUN zoning, SAN fabric is configured to match LUNs to the proper servers. As a rule, end devices such as hosts can only see and access storage within their zone. Limiting access in this way improves security and allows bandwidth allocation through assigning particular ports to a zone.

LUN masking is a further constraint added to zoning, subdividing access to the port so that only LUNs authorized to access a specific server can access the corresponding port. Then, even if several LUNs are accessed through the same port, the server masks can be set to limit each server's access to the appropriate LUNs. LUN masking is typically conducted at the host bus adapter (HBA) or switch level.



Note: The logical unit described above is different from the logical unit of IBM's Systems Network Architecture (SNA).

ความสามารถครั้งใหญ่ของ Virtual Machine File System 5 (VMFS-5)

ความสามารถครั้งใหญ่ของ Virtual Machine File System 5 (VMFS-5) การปรับเปลี่ยนเวอร์ชั่นใหม่ของโครงสร้างเวอร์ชวลไลเซชั่นระดับโลกอย่าง VMware vSphere ขึ้นมาเป็นเวอร์ชั่น 5 ย่อมทำให้องค์ประกอบหลายส่วนภายในถูกขยับตามไปอย่างอหังการ์ หนึ่งในนั้นคือระบบไฟล์อันมีนามว่า Virtual Machine File System (VMFS) ถูกเปลี่ยนจากเวอร์ชั่น 3.46 มาเป็น 5 อย่างเลี่ยงไม่ได้ และนี่คือความสามารถครั้งใหม่และใหญ่ของ VMFS-5 ศักยภาพใหญ่ๆ บล็อกขนาด 1 เมกกะไบต์ถ้วนทั่วกัน (Unified 1MB Block Size) – บน VMFS-3 ขนาดของบล็อกมีหลากหลายตั้งแต่ 1, 2, 4 และ 8 เมกกะไบต์ (MB) เวลาเราสร้างดาต้าสโตร์ (Datastore) จำเป็นต้องระบุขนาดให้เหมาะสม เพื่อให้เราสามารถสร้างไฟล์ขนาดใหญ่ได้ตามความต้องการ แต่บน VMFS-5 ขนาดของบล็อคจะยืนอยู่ที่ 1 เมกกะไบต์ตลอดศก ไม่มีให้เลือกอีกแล้ว ลดความวุ่นวายไปได้อยู่โข ขนาดวอลลุ่มใหม่ใหญ่อหังการ์ (Large Single Extent Volumes) – ในเวอร์ชั่นเก่าวอลลุ่มที่รองรับใหญ่สุดเพียงแค่ 2 เทราไบต์ (TB) มาคราวนี้มีให้เราได้เล่นเลยเถิดกันไปถึง ~60 เทราไบต์…. อะไรจะไขนนาด ขนาดบล็อคย่อยลดลงไป (Small Sub-Block) – เดิมทีเราใช้บล็อคย่อยมีขนาด 64 กิโลไบต์ (64KB) มาคราวนี้วีเอ็มแวร์ลดลงให้เล็กสุดใจเหลือแค่ 8 กิโลไบต์ (8KB) เท่านั้น นั่นทำให้ไฟล์ขนาดเล็กกว่า 8 กิโลไบต์ (แต่ใหญ่กว่า 1 กิโลไบต์) จะไม่ต้องใช้พื้นที่ขนาด 64 กิโลไบต์ในการจัดเก็บ ทำให้ได้พื้นที่คืนมามากอยู่ รองรับไฟล์เล็กๆ ได้ดีขึ้น (Small File Support) – บน VMFS-5 สำหรับไฟล์ขนาดเล็กกว่า 1 กิโลไบต์ จะไม่ได้เก็บอยู่ในบล็อคย่อยขนาด 8 กิโลไบต์เพียงไฟล์เดียว มันเปลืองเกินไป ระบบจะทำการจัดเก็บไฟล์ย่อยๆ ขนาด 1 กิโลไบต์ไว้รวมๆ กันในบล็อคย่อย แล้วเก็บตำแหน่งของไฟล์ไว้ใน metadata สำหรับเรียกหาไฟล์เมื่อต้องการ และเมื่อไฟล์บางไฟล์เริ่มโตขึ้นจนมีขนาดใหญ่โตเกินกว่า 1 กิโลไบต์ มันก็จะถูกแยกออกไปอยู่ในบล็อคย่อยขนาด 8 กิโลไบต์ของมันเองเป็นเอกเทศ จำนวนไฟล์ก็มากขึ้น (Increased File Count) – บน VMFS-5 รองรับจำนวนไฟล์ได้มากกว่า 100,000 ไฟล์ เพิ่มขึ้นมากกว่า 3 เท่าตัว จากที่ VMFS-3 รับได้ที่ประมาณ 30,000 ไฟล์ต่อดาต้าสโตร์เท่านั้น เพิ่มเติมการทำงานของ Atomic Test & Set (ATS Enhancement) – Atomic Test & Set (ATS) เป็นคุณสมบัติในการจัดการไฟล์บน VMFS ที่ได้ถูกเพิ่มเติมเข้ามาใหม่บนความสามารถ vSphere Storage APIs for Array Integration (VAAI) เมื่อตอน vSphere 4.1 มาคราวนี้มันมาแบบจัดเต็ม ความสามารถ ATS จะอยู่บนทุกอณูของ VMFS-5 ทำให้ประสิทธิภาพในการล็อค (Lock) ก่อนจะทำการเขียนข้อมูลทำได้หรูยิ่งขึ้น การอัพเกรดจาก VMFS-3 ไปเป็น VMFS-5 ทำได้โดยไม่มีดาวน์ไทม์ (Downtime) นั่นหมายความว่าเวอร์ชวลแมชชีน (Virtual Machine) ทำงานต่อไปได้แม้เราจะทำอัพเกรดดาต้าสโตร์อยู่ เมื่ออัพเกรดแล้ว ไฟล์เล็กๆ ที่มีขนาดเล็กกว่า 1 กิโลไบต์ก็จะไปอยู่รวมกันเป็นที่เป็นทางในบล็อคย่อยๆ เพื่อไม่ให้เปลืองพื้นที่ เมื่ออัพเกรดแล้ววอลลุ่มก็จะสามารถใหญ่ได้สุดๆ ~60 เทราไบต์ และแน่นอนจะได้ความสามารถ ATS เข้าสู่วอลลุ่มหรือดาต้าสโตร์นั้นโดยพลัน ความแตกต่างระหว่างสร้าง VMFS-5 ขึ้นมาใหม่ กับการอัพเกรดจาก VMFS-3 เมื่ออัพเกรดมา ขนาดบล็อคจะเป็นขนาดเดิมที่เคยเป็น ไม่ได้ปรับมาเป็นขนาด 1 เมกกะไบต์ให้ เมื่ออัพเกรดมา ขนาดบล็อคย่อยจะเป็น 64 กิโลไบต์ ไม่ใช่ขนาด 8 กิโลไบต์ตามโครงสร้างใหม่ เมื่ออัพเกรดมา จำนวนไฟล์ที่รองรับจะเป็น 30,720 ไฟล์เหมือนเดิม ไม่ได้เพิ่มขึ้น เมื่ออัพเกรดมา รูปแบบพาร์ทิชั่น (Partition) จะเป็น Master Boot Record (MBR) สำหรับวอลลุ่มที่ไม่เกิน 2 เทราไบต์ เมื่อมันเกิน พาร์ทิชั่นจะเปลี่ยนเป็นแบบ GUID Partition Table (GPT) ให้อัตโนมัติ โดยที่เวอร์ชวลแมชชีนยังคงทำงานได้ไม่มีผลกระทบ เมื่ออัพเกรดมา พาร์ทิชั่นจะเริ่มทำงานที่เซคเตอร์ (Sector) 128 แต่หากสร้างเป็น VMFS-5 ขึ้นมาใหม่ การทำงานจะเริ่มที่เซคเตอร์ 2048 นะครับ ดิสก์แบบต่อตรง (Raw Device Mapping – RDM) RDM แบบ Passthru (Physical) จะรองรับขนาดได้มหึมา ~60 เทราไบต์ ไม่ว่าจะอัพเกรดมาหรือสร้างใหม่ RDM แบบ Non-Passthru (Virtual) จะคงมีขนาด 2 เทราไบต์ ลบด้วย 512 ไบต์ (2TB-512B) อื่นๆ อีกมากมาย ขนาดไฟล์ VMDK ใหญ่ที่สุดบน VMFS-5 ยังคงได้แค่ 2 เทราไบต์ ลบด้วย 512 ไบต์ (2TB-512B) จำนวนลัน (LUN) รองรับได้สูงสุด 256 ลัน บน ESXi 5.0 คำแนะนำเอย จงสร้างดาต้าสโตร์ VMFS-5 ขึ้นมาใหม่เสียเถิด เพื่อให้รองรับความสามารถใหม่ๆ ให้ได้เป็นอย่างดี นั่นหมายความว่าเราจำต้องนำเอาความสามารถ Storage vMotion เข้ามาช่วย เพื่อย้ายเวอร์ชวลแมชชีนออกไปก่อน แล้วล้างดาต้าสโตร์ VMFS-3 ทิ้งไป ก่อนสร้างใหม่เป็น VMFS-5 แล้วนำเวอร์ชวลแมชชีนกลับคืนรัง ด้วยประการฉะนี้จะทำให้เวอร์ชวลแมชชีนไร้ซึ่งดาวน์ไทม์เอย ที่มา : http://blogs.vmware.com/vsphere/2011/07/new-vsphere-50-storage-features-part-1-vmfs-5.html

วันพฤหัสบดีที่ 22 พฤศจิกายน พ.ศ. 2555

Vm ware 5 Disk Type


There are three options for allocating space out of your storage for your VM disks:
Thick Provisioning Lazy Zeroed: Allocates the disk space statically (no other volumes can take the space), but doesn’t write zeros to the blocks until the first write takes place to that block during runtime (which includes a full disk format).
Thick Provisioning Eager Zeroed: Allocates the disk space statically (no other volumes can take the space), and writes zeros to all the blocks.
Thin Provisioning: Allocates the disk space only when a write occurs to a block, but the total volume size is reported by VMFS to the OS. Other volumes can take the remaining space. This allows you to float space between your servers, and expand your storage when your size monitoring indicates there’s a problem. Note that once a Thin Provisioned block is allocated, it remains on the volume regardless if you’ve deleted data, etc.
By definition, you would expect Thick Provisioning Eager Zeroed to be the fastest.
A quick search turned up both a rudimentary benchmark and a whitepaper that covers disk provisioning in much greater detail and provides a benchmark.
So, of course, the whitepaper proves that Thick Provisioning Eager Zeroed is going to get you the most throughput from an SQL DB or ESE DB. But it might be wise to even use Thin provisioning, then force the DB to grow, if possible scheduling the growth off hours.
The same goes for thin provisioning on a SAN, but that’s another day.