diff --git a/documentation/content/en/articles/vinum/_index.adoc b/documentation/content/en/articles/vinum/_index.adoc index 3fc70ed9b4..abb5ee8c90 100644 --- a/documentation/content/en/articles/vinum/_index.adoc +++ b/documentation/content/en/articles/vinum/_index.adoc @@ -1,700 +1,710 @@ --- title: The vinum Volume Manager authors: - author: Greg Lehey description: The vinum Volume Manager in FreeBSD tags: ["vinum", "Volume Manager", "FreeBSD"] --- +//// +The Vinum Volume Manager +By Greg Lehey (grog at lemis dot com) + +Added to the Handbook by Hiten Pandya +and Tom Rhodes + +For the FreeBSD Documentation Project +//// + = The vinum Volume Manager :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: ifeval::["{backend}" == "html5"] include::shared/en/urls.adoc[] :imagesdir: ../../../images/articles/vinum/ endif::[] ifeval::["{backend}" == "pdf"] include::../../../../shared/en/urls.adoc[] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] ifeval::["{backend}" == "epub3"] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] ''' toc::[] [[vinum-synopsis]] == Synopsis No matter the type of disks, there are always potential problems. The disks can be too small, too slow, or too unreliable to meet the system's requirements. While disks are getting bigger, so are data storage requirements. Often a file system is needed that is bigger than a disk's capacity. Various solutions to these problems have been proposed and implemented. One method is through the use of multiple, and sometimes redundant, disks. In addition to supporting various cards and controllers for hardware Redundant Array of Independent Disks RAID systems, the base FreeBSD system includes the [.filename]#vinum# volume manager, a block device driver that implements virtual disk drives and addresses these three problems. [.filename]#vinum# provides more flexibility, performance, and reliability than traditional disk storage and implements `RAID`-0, `RAID`-1, and `RAID`-5 models, both individually and in combination. This chapter provides an overview of potential problems with traditional disk storage, and an introduction to the [.filename]#vinum# volume manager. [NOTE] ==== Starting with FreeBSD 5, [.filename]#vinum# has been rewritten in order to fit into the link:{handbook}#geom[GEOM architecture], while retaining the original ideas, terminology, and on-disk metadata. This rewrite is called _gvinum_ (for _GEOM vinum_). While this chapter uses the term [.filename]#vinum#, any command invocations should be performed with `gvinum`. The name of the kernel module has changed from the original [.filename]#vinum.ko# to [.filename]#geom_vinum.ko#, and all device nodes reside under [.filename]#/dev/gvinum# instead of [.filename]#/dev/vinum#. As of FreeBSD 6, the original [.filename]#vinum# implementation is no longer available in the code base. ==== [[vinum-access-bottlenecks]] == Access Bottlenecks Modern systems frequently need to access data in a highly concurrent manner. For example, large FTP or HTTP servers can maintain thousands of concurrent sessions and have multiple 100 Mbit/s connections to the outside world, well beyond the sustained transfer rate of most disks. Current disk drives can transfer data sequentially at up to 70 MB/s, but this value is of little importance in an environment where many independent processes access a drive, and where they may achieve only a fraction of these values. In such cases, it is more interesting to view the problem from the viewpoint of the disk subsystem. The important parameter is the load that a transfer places on the subsystem, or the time for which a transfer occupies the drives involved in the transfer. In any disk transfer, the drive must first position the heads, wait for the first sector to pass under the read head, and then perform the transfer. These actions can be considered to be atomic as it does not make any sense to interrupt them. [[vinum-latency]] Consider a typical transfer of about 10 kB: the current generation of high-performance disks can position the heads in an average of 3.5 ms. The fastest drives spin at 15,000 rpm, so the average rotational latency (half a revolution) is 2 ms. At 70 MB/s, the transfer itself takes about 150 μs, almost nothing compared to the positioning time. In such a case, the effective transfer rate drops to a little over 1 MB/s and is clearly highly dependent on the transfer size. The traditional and obvious solution to this bottleneck is "more spindles": rather than using one large disk, use several smaller disks with the same aggregate storage space. Each disk is capable of positioning and transferring independently, so the effective throughput increases by a factor close to the number of disks used. The actual throughput improvement is smaller than the number of disks involved. Although each drive is capable of transferring in parallel, there is no way to ensure that the requests are evenly distributed across the drives. Inevitably the load on one drive will be higher than on another. The evenness of the load on the disks is strongly dependent on the way the data is shared across the drives. In the following discussion, it is convenient to think of the disk storage as a large number of data sectors which are addressable by number, rather like the pages in a book. The most obvious method is to divide the virtual disk into groups of consecutive sectors the size of the individual physical disks and store them in this manner, rather like taking a large book and tearing it into smaller sections. This method is called _concatenation_ and has the advantage that the disks are not required to have any specific size relationships. It works well when the access to the virtual disk is spread evenly about its address space. When access is concentrated on a smaller area, the improvement is less marked. <> illustrates the sequence in which storage units are allocated in a concatenated organization. [[vinum-concat]] .Concatenated Organization image::vinum-concat.png[] An alternative mapping is to divide the address space into smaller, equal-sized components and store them sequentially on different devices. For example, the first 256 sectors may be stored on the first disk, the next 256 sectors on the next disk and so on. After filling the last disk, the process repeats until the disks are full. This mapping is called _striping_ or RAID-0. `RAID` offers various forms of fault tolerance, though RAID-0 is somewhat misleading as it provides no redundancy. Striping requires somewhat more effort to locate the data, and it can cause additional I/O load where a transfer is spread over multiple disks, but it can also provide a more constant load across the disks. <> illustrates the sequence in which storage units are allocated in a striped organization. [[vinum-striped]] .Striped Organization image::vinum-striped.png[] [[vinum-data-integrity]] == Data Integrity The final problem with disks is that they are unreliable. Although reliability has increased tremendously over the last few years, disk drives are still the most likely core component of a server to fail. When they do, the results can be catastrophic and replacing a failed disk drive and restoring data can result in server downtime. One approach to this problem is _mirroring_, or `RAID-1`, which keeps two copies of the data on different physical hardware. Any write to the volume writes to both disks; a read can be satisfied from either, so if one drive fails, the data is still available on the other drive. Mirroring has two problems: * It requires twice as much disk storage as a non-redundant solution. * Writes must be performed to both drives, so they take up twice the bandwidth of a non-mirrored volume. Reads do not suffer from a performance penalty and can even be faster. An alternative solution is _parity_, implemented in `RAID` levels 2, 3, 4 and 5. Of these, `RAID-5` is the most interesting. As implemented in [.filename]#vinum#, it is a variant on a striped organization which dedicates one block of each stripe to parity one of the other blocks. As implemented by [.filename]#vinum#, a `RAID-5` plex is similar to a striped plex, except that it implements `RAID-5` by including a parity block in each stripe. As required by `RAID-5`, the location of this parity block changes from one stripe to the next. The numbers in the data blocks indicate the relative block numbers. [[vinum-raid5-org]] .`RAID`-5 Organization image::vinum-raid5-org.png[] Compared to mirroring, `RAID-5` has the advantage of requiring significantly less storage space. Read access is similar to that of striped organizations, but write access is significantly slower, approximately 25% of the read performance. If one drive fails, the array can continue to operate in degraded mode where a read from one of the remaining accessible drives continues normally, but a read from the failed drive is recalculated from the corresponding block from all the remaining drives. [[vinum-objects]] == [.filename]#vinum# Objects In order to address these problems, [.filename]#vinum# implements a four-level hierarchy of objects: * The most visible object is the virtual disk, called a _volume_. Volumes have essentially the same properties as a UNIX(R) disk drive, though there are some minor differences. For one, they have no size limitations. * Volumes are composed of _plexes_, each of which represent the total address space of a volume. This level in the hierarchy provides redundancy. Think of plexes as individual disks in a mirrored array, each containing the same data. * Since [.filename]#vinum# exists within the UNIX(R) disk storage framework, it would be possible to use UNIX(R) partitions as the building block for multi-disk plexes. In fact, this turns out to be too inflexible as UNIX(R) disks can have only a limited number of partitions. Instead, [.filename]#vinum# subdivides a single UNIX(R) partition, the _drive_, into contiguous areas called _subdisks_, which are used as building blocks for plexes. * Subdisks reside on [.filename]#vinum#_drives_, currently UNIX(R) partitions. [.filename]#vinum# drives can contain any number of subdisks. With the exception of a small area at the beginning of the drive, which is used for storing configuration and state information, the entire drive is available for data storage. The following sections describe the way these objects provide the functionality required of [.filename]#vinum#. === Volume Size Considerations Plexes can include multiple subdisks spread over all drives in the [.filename]#vinum# configuration. As a result, the size of an individual drive does not limit the size of a plex or a volume. === Redundant Data Storage [.filename]#vinum# implements mirroring by attaching multiple plexes to a volume. Each plex is a representation of the data in a volume. A volume may contain between one and eight plexes. Although a plex represents the complete data of a volume, it is possible for parts of the representation to be physically missing, either by design (by not defining a subdisk for parts of the plex) or by accident (as a result of the failure of a drive). As long as at least one plex can provide the data for the complete address range of the volume, the volume is fully functional. === Which Plex Organization? [.filename]#vinum# implements both concatenation and striping at the plex level: * A _concatenated plex_ uses the address space of each subdisk in turn. Concatenated plexes are the most flexible as they can contain any number of subdisks, and the subdisks may be of different length. The plex may be extended by adding additional subdisks. They require less CPU time than striped plexes, though the difference in CPU overhead is not measurable. On the other hand, they are most susceptible to hot spots, where one disk is very active and others are idle. * A _striped plex_ stripes the data across each subdisk. The subdisks must all be the same size and there must be at least two subdisks in order to distinguish it from a concatenated plex. The greatest advantage of striped plexes is that they reduce hot spots. By choosing an optimum sized stripe, about 256 kB, the load can be evened out on the component drives. Extending a plex by adding new subdisks is so complicated that [.filename]#vinum# does not implement it. <> summarizes the advantages and disadvantages of each plex organization. [[vinum-comparison]] .[.filename]#vinum# Plex Organizations [cols="1,1,1,1,1", frame="none", options="header"] |=== | Plex type | Minimum subdisks | Can add subdisks | Must be equal size | Application |concatenated |1 |yes |no |Large data storage with maximum placement flexibility and moderate performance |striped |2 |no |yes |High performance in combination with highly concurrent access |=== [[vinum-examples]] == Some Examples [.filename]#vinum# maintains a _configuration database_ which describes the objects known to an individual system. Initially, the user creates the configuration database from one or more configuration files using man:gvinum[8]. [.filename]#vinum# stores a copy of its configuration database on each disk _device_ under its control. This database is updated on each state change, so that a restart accurately restores the state of each [.filename]#vinum# object. === The Configuration File The configuration file describes individual [.filename]#vinum# objects. The definition of a simple volume might be: [.programlisting] .... drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a .... This file describes four [.filename]#vinum# objects: * The _drive_ line describes a disk partition (_drive_) and its location relative to the underlying hardware. It is given the symbolic name _a_. This separation of symbolic names from device names allows disks to be moved from one location to another without confusion. * The _volume_ line describes a volume. The only required attribute is the name, in this case _myvol_. * The _plex_ line defines a plex. The only required parameter is the organization, in this case _concat_. No name is necessary as the system automatically generates a name from the volume name by adding the suffix _.px_, where _x_ is the number of the plex in the volume. Thus this plex will be called _myvol.p0_. * The _sd_ line describes a subdisk. The minimum specifications are the name of a drive on which to store it, and the length of the subdisk. No name is necessary as the system automatically assigns names derived from the plex name by adding the suffix _.sx_, where _x_ is the number of the subdisk in the plex. Thus [.filename]#vinum# gives this subdisk the name _myvol.p0.s0_. After processing this file, man:gvinum[8] produces the following output: [.programlisting] .... # gvinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB .... This output shows the brief listing format of man:gvinum[8]. It is represented graphically in <>. [[vinum-simple-vol]] .A Simple [.filename]#vinum# Volume image::vinum-simple-vol.png[] This figure, and the ones which follow, represent a volume, which contains the plexes, which in turn contains the subdisks. In this example, the volume contains one plex, and the plex contains one subdisk. This particular volume has no specific advantage over a conventional disk partition. It contains a single plex, so it is not redundant. The plex contains a single subdisk, so there is no difference in storage allocation from a conventional disk partition. The following sections illustrate various more interesting configuration methods. === Increased Resilience: Mirroring The resilience of a volume can be increased by mirroring. When laying out a mirrored volume, it is important to ensure that the subdisks of each plex are on different drives, so that a drive failure will not take down both plexes. The following configuration mirrors a volume: [.programlisting] .... drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b .... In this example, it was not necessary to specify a definition of drive _a_ again, since [.filename]#vinum# keeps track of all objects in its configuration database. After processing this definition, the configuration looks like: [.programlisting] .... Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB .... <> shows the structure graphically. [[vinum-mirrored-vol]] .A Mirrored [.filename]#vinum# Volume image::vinum-mirrored-vol.png[] In this example, each plex contains the full 512 MB of address space. As in the previous example, each plex contains only a single subdisk. === Optimizing Performance The mirrored volume in the previous example is more resistant to failure than an unmirrored volume, but its performance is less as each write to the volume requires a write to both drives, using up a greater proportion of the total disk bandwidth. Performance considerations demand a different approach: instead of mirroring, the data is striped across as many disk drives as possible. The following configuration shows a volume with a plex striped across four disk drives: [.programlisting] .... drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d .... As before, it is not necessary to define the drives which are already known to [.filename]#vinum#. After processing this definition, the configuration looks like: [.programlisting] .... Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB .... [[vinum-striped-vol]] .A Striped [.filename]#vinum# Volume image::vinum-striped-vol.png[] This volume is represented in <>. The darkness of the stripes indicates the position within the plex address space, where the lightest stripes come first and the darkest last. === Resilience and Performance [[vinum-resilience]]With sufficient hardware, it is possible to build volumes which show both increased resilience and increased performance compared to standard UNIX(R) partitions. A typical configuration file might be: [.programlisting] .... volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b .... The subdisks of the second plex are offset by two drives from those of the first plex. This helps to ensure that writes do not go to the same subdisks even if a transfer goes over two drives. <> represents the structure of this volume. [[vinum-raid10-vol]] .A Mirrored, Striped [.filename]#vinum# Volume image::vinum-raid10-vol.png[] [[vinum-object-naming]] == Object Naming [.filename]#vinum# assigns default names to plexes and subdisks, although they may be overridden. Overriding the default names is not recommended as it does not bring a significant advantage and it can cause confusion. Names may contain any non-blank character, but it is recommended to restrict them to letters, digits and the underscore characters. The names of volumes, plexes, and subdisks may be up to 64 characters long, and the names of drives may be up to 32 characters long. [.filename]#vinum# objects are assigned device nodes in the hierarchy [.filename]#/dev/gvinum#. The configuration shown above would cause [.filename]#vinum# to create the following device nodes: * Device entries for each volume. These are the main devices used by [.filename]#vinum#. The configuration above would include the devices [.filename]#/dev/gvinum/myvol#, [.filename]#/dev/gvinum/mirror#, [.filename]#/dev/gvinum/striped#, [.filename]#/dev/gvinum/raid5# and [.filename]#/dev/gvinum/raid10#. * All volumes get direct entries under [.filename]#/dev/gvinum/#. * The directories [.filename]#/dev/gvinum/plex#, and [.filename]#/dev/gvinum/sd#, which contain device nodes for each plex and for each subdisk, respectively. For example, consider the following configuration file: [.programlisting] .... drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4 .... After processing this file, man:gvinum[8] creates the following structure in [.filename]#/dev/gvinum#: [.programlisting] .... drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd /dev/vinum/plex: total 0 crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/sd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 .... Although it is recommended that plexes and subdisks should not be allocated specific names, [.filename]#vinum# drives must be named. This makes it possible to move a drive to a different location and still recognize it automatically. Drive names may be up to 32 characters long. === Creating File Systems Volumes appear to the system to be identical to disks, with one exception. Unlike UNIX(R) drives, [.filename]#vinum# does not partition volumes, which thus do not contain a partition table. This has required modification to some disk utilities, notably man:newfs[8], so that it does not try to interpret the last letter of a [.filename]#vinum# volume name as a partition identifier. For example, a disk drive may have a name like [.filename]#/dev/ad0a# or [.filename]#/dev/da2h#. These names represent the first partition ([.filename]#a#) on the first (0) IDE disk ([.filename]#ad#) and the eighth partition ([.filename]#h#) on the third (2) SCSI disk ([.filename]#da#) respectively. By contrast, a [.filename]#vinum# volume might be called [.filename]#/dev/gvinum/concat#, which has no relationship with a partition name. In order to create a file system on this volume, use man:newfs[8]: [source,shell] .... # newfs /dev/gvinum/concat .... [[vinum-config]] == Configuring [.filename]#vinum# The [.filename]#GENERIC# kernel does not contain [.filename]#vinum#. It is possible to build a custom kernel which includes [.filename]#vinum#, but this is not recommended. The standard way to start [.filename]#vinum# is as a kernel module. man:kldload[8] is not needed because when man:gvinum[8] starts, it checks whether the module has been loaded, and if it is not, it loads it automatically. === Startup [.filename]#vinum# stores configuration information on the disk slices in essentially the same form as in the configuration files. When reading from the configuration database, [.filename]#vinum# recognizes a number of keywords which are not allowed in the configuration files. For example, a disk configuration might contain the following text: [.programlisting] .... volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b .... The obvious differences here are the presence of explicit location information and naming, both of which are allowed but discouraged, and the information on the states. [.filename]#vinum# does not store information about drives in the configuration information. It finds the drives by scanning the configured disk drives for partitions with a [.filename]#vinum# label. This enables [.filename]#vinum# to identify drives correctly even if they have been assigned different UNIX(R) drive IDs. [[vinum-rc-startup]] ==== Automatic Startup _Gvinum_ always features an automatic startup once the kernel module is loaded, via man:loader.conf[5]. To load the _Gvinum_ module at boot time, add `geom_vinum_load="YES"` to [.filename]#/boot/loader.conf#. When [.filename]#vinum# is started with `gvinum start`, [.filename]#vinum# reads the configuration database from one of the [.filename]#vinum# drives. Under normal circumstances, each drive contains an identical copy of the configuration database, so it does not matter which drive is read. After a crash, however, [.filename]#vinum# must determine which drive was updated most recently and read the configuration from this drive. It then updates the configuration, if necessary, from progressively older drives. [[vinum-root]] == Using [.filename]#vinum# for the Root File System For a machine that has fully-mirrored file systems using [.filename]#vinum#, it is desirable to also mirror the root file system. Setting up such a configuration is less trivial than mirroring an arbitrary file system because: * The root file system must be available very early during the boot process, so the [.filename]#vinum# infrastructure must already be available at this time. * The volume containing the root file system also contains the system bootstrap and the kernel. These must be read using the host system's native utilities, such as the BIOS, which often cannot be taught about the details of [.filename]#vinum#. In the following sections, the term "root volume" is generally used to describe the [.filename]#vinum# volume that contains the root file system. === Starting up [.filename]#vinum# Early Enough for the Root File System [.filename]#vinum# must be available early in the system boot as man:loader[8] must be able to load the vinum kernel module before starting the kernel. This can be accomplished by putting this line in [.filename]#/boot/loader.conf#: [.programlisting] .... geom_vinum_load="YES" .... === Making a [.filename]#vinum#-based Root Volume Accessible to the Bootstrap The current FreeBSD bootstrap is only 7.5 KB of code and does not understand the internal [.filename]#vinum# structures. This means that it cannot parse the [.filename]#vinum# configuration data or figure out the elements of a boot volume. Thus, some workarounds are necessary to provide the bootstrap code with the illusion of a standard `a` partition that contains the root file system. For this to be possible, the following requirements must be met for the root volume: * The root volume must not be a stripe or `RAID`-5. * The root volume must not contain more than one concatenated subdisk per plex. Note that it is desirable and possible to use multiple plexes, each containing one replica of the root file system. The bootstrap process will only use one replica for finding the bootstrap and all boot files, until the kernel mounts the root file system. Each single subdisk within these plexes needs its own `a` partition illusion, for the respective device to be bootable. It is not strictly needed that each of these faked `a` partitions is located at the same offset within its device, compared with other devices containing plexes of the root volume. However, it is probably a good idea to create the [.filename]#vinum# volumes that way so the resulting mirrored devices are symmetric, to avoid confusion. In order to set up these `a` partitions for each device containing part of the root volume, the following is required: [.procedure] ==== . The location, offset from the beginning of the device, and size of this device's subdisk that is part of the root volume needs to be examined, using the command: + [source,shell] .... # gvinum l -rv root .... + [.filename]#vinum# offsets and sizes are measured in bytes. They must be divided by 512 in order to obtain the block numbers that are to be used by `bsdlabel`. . Run this command for each device that participates in the root volume: + [source,shell] .... # bsdlabel -e devname .... + _devname_ must be either the name of the disk, like [.filename]#da0# for disks without a slice table, or the name of the slice, like [.filename]#ad0s1#. + If there is already an `a` partition on the device from a pre-[.filename]#vinum# root file system, it should be renamed to something else so that it remains accessible (just in case), but will no longer be used by default to bootstrap the system. A currently mounted root file system cannot be renamed, so this must be executed either when being booted from a "Fixit" media, or in a two-step process where, in a mirror, the disk that is not been currently booted is manipulated first. + The offset of the [.filename]#vinum# partition on this device (if any) must be added to the offset of the respective root volume subdisk on this device. The resulting value will become the `offset` value for the new `a` partition. The `size` value for this partition can be taken verbatim from the calculation above. The `fstype` should be `4.2BSD`. The `fsize`, `bsize`, and `cpg` values should be chosen to match the actual file system, though they are fairly unimportant within this context. + That way, a new `a` partition will be established that overlaps the [.filename]#vinum# partition on this device. `bsdlabel` will only allow for this overlap if the [.filename]#vinum# partition has properly been marked using the `vinum` fstype. . A faked `a` partition now exists on each device that has one replica of the root volume. It is highly recommendable to verify the result using a command like: + [source,shell] .... # fsck -n /dev/devnamea .... ==== It should be remembered that all files containing control information must be relative to the root file system in the [.filename]#vinum# volume which, when setting up a new [.filename]#vinum# root volume, might not match the root file system that is currently active. So in particular, [.filename]#/etc/fstab# and [.filename]#/boot/loader.conf# need to be taken care of. At next reboot, the bootstrap should figure out the appropriate control information from the new [.filename]#vinum#-based root file system, and act accordingly. At the end of the kernel initialization process, after all devices have been announced, the prominent notice that shows the success of this setup is a message like: [source,shell] .... Mounting root from ufs:/dev/gvinum/root .... === Example of a [.filename]#vinum#-based Root Setup After the [.filename]#vinum# root volume has been set up, the output of `gvinum l -rv root` could look like: [source,shell] .... ... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB) .... The values to note are `135680` for the offset, relative to partition [.filename]#/dev/da0h#. This translates to 265 512-byte disk blocks in `bsdlabel`'s terms. Likewise, the size of this root volume is 245760 512-byte blocks. [.filename]#/dev/da1h#, containing the second replica of this root volume, has a symmetric setup. The bsdlabel for these devices might look like: [source,shell] .... ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*) .... It can be observed that the `size` parameter for the faked `a` partition matches the value outlined above, while the `offset` parameter is the sum of the offset within the [.filename]#vinum# partition `h`, and the offset of this partition within the device or slice. This is a typical setup that is necessary to avoid the problem described in <>. The entire `a` partition is completely within the `h` partition containing all the [.filename]#vinum# data for this device. In the above example, the entire device is dedicated to [.filename]#vinum# and there is no leftover pre-[.filename]#vinum# root partition. === Troubleshooting The following list contains a few known pitfalls and solutions. ==== System Bootstrap Loads, but System Does Not Boot If for any reason the system does not continue to boot, the bootstrap can be interrupted by pressing kbd:[space] at the 10-seconds warning. The loader variable `vinum.autostart` can be examined by typing `show` and manipulated using `set` or `unset`. If the [.filename]#vinum# kernel module was not yet in the list of modules to load automatically, type `load geom_vinum`. When ready, the boot process can be continued by typing `boot -as` which `-as` requests the kernel to ask for the root file system to mount (`-a`) and make the boot process stop in single-user mode (`-s`), where the root file system is mounted read-only. That way, even if only one plex of a multi-plex volume has been mounted, no data inconsistency between plexes is being risked. At the prompt asking for a root file system to mount, any device that contains a valid root file system can be entered. If [.filename]#/etc/fstab# is set up correctly, the default should be something like `ufs:/dev/gvinum/root`. A typical alternate choice would be something like `ufs:da0d` which could be a hypothetical partition containing the pre-[.filename]#vinum# root file system. Care should be taken if one of the alias `a` partitions is entered here, that it actually references the subdisks of the [.filename]#vinum# root device, because in a mirrored setup, this would only mount one piece of a mirrored root device. If this file system is to be mounted read-write later on, it is necessary to remove the other plex(es) of the [.filename]#vinum# root volume since these plexes would otherwise carry inconsistent data. ==== Only Primary Bootstrap Loads If [.filename]#/boot/loader# fails to load, but the primary bootstrap still loads (visible by a single dash in the left column of the screen right after the boot process starts), an attempt can be made to interrupt the primary bootstrap by pressing kbd:[space]. This will make the bootstrap stop in link:{handbook}#boot-boot1[stage two]. An attempt can be made here to boot off an alternate partition, like the partition containing the previous root file system that has been moved away from `a`. [[vinum-root-panic]] ==== Nothing Boots, the Bootstrap Panics This situation will happen if the bootstrap had been destroyed by the [.filename]#vinum# installation. Unfortunately, [.filename]#vinum# accidentally leaves only 4 KB at the beginning of its partition free before starting to write its [.filename]#vinum# header information. However, the stage one and two bootstraps plus the bsdlabel require 8 KB. So if a [.filename]#vinum# partition was started at offset 0 within a slice or disk that was meant to be bootable, the [.filename]#vinum# setup will trash the bootstrap. Similarly, if the above situation has been recovered, by booting from a "Fixit" media, and the bootstrap has been re-installed using `bsdlabel -B` as described in link:{handbook}#boot-boot1[stage two], the bootstrap will trash the [.filename]#vinum# header, and [.filename]#vinum# will no longer find its disk(s). Though no actual [.filename]#vinum# configuration data or data in [.filename]#vinum# volumes will be trashed, and it would be possible to recover all the data by entering exactly the same [.filename]#vinum# configuration data again, the situation is hard to fix. It is necessary to move the entire [.filename]#vinum# partition by at least 4 KB, in order to have the [.filename]#vinum# header and the system bootstrap no longer collide. diff --git a/documentation/content/es/articles/vinum/_index.adoc b/documentation/content/es/articles/vinum/_index.adoc index 036349e974..4f3a47b710 100644 --- a/documentation/content/es/articles/vinum/_index.adoc +++ b/documentation/content/es/articles/vinum/_index.adoc @@ -1,580 +1,590 @@ --- authors: - author: 'Greg Lehey' description: 'El Gestor de Volúmenes vinum en FreeBSD' tags: ["vinum", "Volume Manager", "FreeBSD"] title: 'El Gestor de Volúmenes vinum' --- +//// +The Vinum Volume Manager +By Greg Lehey (grog at lemis dot com) + +Added to the Handbook by Hiten Pandya +and Tom Rhodes + +For the FreeBSD Documentation Project +//// + = El Gestor de Volúmenes vinum :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: ifeval::["{backend}" == "html5"] include::shared/es/urls.adoc[] :imagesdir: ../../../images/articles/vinum/ endif::[] ifeval::["{backend}" == "pdf"] include::../../../../shared/es/urls.adoc[] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] ifeval::["{backend}" == "epub3"] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] ''' toc::[] [[vinum-synopsis]] == Sinopsis Independientemente del tipo de disco, siempre hay problemas potenciales. Los discos pueden ser muy pequeños, muy lentos, o muy poco fiables para cumplir con los requisitos del sistema. Aunque los discos crecen, también lo hacen los requisitos de almacenamiento. A menudo se necesita un sistema de ficheros que es mayor que la capacidad del disco. Se han propuesto e implementado varias soluciones a estos problemas. Un método es mediante el uso de múltiples, y a veces redundantes, discos. Además de soportar varias tarjetas y controladores hardware de sistemas de Arrays Redundantes de Discos Independientes `RAID` , el sistema base de FreeBSD incluye el gestor de volúmenes [.filename]#vinum# , un controlador de dispositivos de bloques que implementa unidades virtuales de disco y que aborda estos tres problemas. [.filename]#vinum# proporciona más flexibilidad, rendimiento, y fiabilidad que el almacenamiento de disco tradicional e implementa los modelos `RAID`-0, `RAID`-1, y `RAID`-5 , tanto individualmente como combinados. Este capítulo proporciona una visión general de los problemas potenciales del almacenamiento tradicional en disco, y una introducción al gestor de volúmenes [.filename]#vinum#. [NOTE] ==== Comenzando con FreeBSD 5, [.filename]#vinum# ha sido reescrito para adaptarlo a la link:{handbook}#geom[arquitectura GEOM], a la vez que se mantienen las ideas originales, terminología, y metadata en disco. Esta reescritura se llama _gvinum_ (por _GEOM vinum_). Aunque este capítulo utiliza el término [.filename]#vinum#, cualquier invocación de comando se debe realizar con `gvinum`. El nombre del módulo del kernel ha cambiado del original [.filename]#vinum.ko# a [.filename]#geom_vinum.ko#, y todos los nodos de dispositivo residen bajo [.filename]#/dev/gvinum# en lugar de [.filename]#/dev/vinum#. A partir de FreeBSD 6, la implementación original de [.filename]#vinum# no está disponible en el código base. ==== [[vinum-access-bottlenecks]] == Cuellos de botella de acceso Los sistemas modernos necesitan frecuentemente acceder a los datos de una forma altamente concurrente. Por ejemplo, grandes servidores de FTP o HTTP pueden mantener miles de sesiones concurrents y tener conexiones de 100 Mbit/s al mundo exterior, mucho más que la tasa de transferencia mantenida de la mayoría de los discos. Las unidades de disco actuales pueden transferir datos secuencialmente hasta unos 70 MB/s, pero este valor tiene poca importancia en un entorno en el que muchos procesos independientes acceden a un dispositivo, y donde solo pueden conseguir una fracción de esos valores. En tales casos, es más interesante ver el problema desde el punto de vista del subsistema de disco. El parámetro importante es la carga que una transferencia supone en el subsistema, o el tiempo para el cual la transferencia ocupa los dispositivos involucrados en la misma. En cualquier transferencia de disco, la unidad debe primero posicionar el cabezal, esperar a que el primer sector pase bajo la cabeza de lectura, y después realizar la transferencia. Estas acciones pueden considerarse atómicas y que no tiene sentido interrumpirlas. [[vinum-latency]] Considera una transferencia típica de unos 10 kB: la generación actual de discos de alto rendimiento pueden situar los cabezales en unos 3.5 ms de media. Los discos más rápidos giran a 15,000 rpm, así que la latencia rotacional media (media revolución) es 2 ms. A 70 MB/s, la propia transferencia tarda unos 150 μs, casi nada comparado con el tiempo de posicionamiento. En ese caso, la tasa efectiva de transferencia cae hasta un poco más de 1 MB/s y depende claramente del tamaño de la transferencia. La solución obvia y tradicional a este cuello de botella es "más agujas": en lugar de usar un gran disco, usar varios discos pequeños con el mismo espacio de almacenamiento agregado. Cada disco es capaz de posicionar y transferir de forma independiente, así que el rendimiento efectivo aumenta en un factor próximo al número de discos utilizados. La mejora de rendimiento real es menor que el número de discos involucrados. Aunque cada dispositivo es capaz de transferir en paralelo, no hay forma de asegurar que las peticiones se distribuyen de forma equilibrada entre los dispositivos. Inevitablemente la carga en un dispositivo será mayor que en otro. El reparto equitativo de la carga en los discos depende fuertemente de la forma en la que los datos se comparten entre los dispositivos. En la siguiente discusión, es conveniente pensar en el almacenamiento de disco como un número grande de sectores que son direccionables mediante un número, parecido a las páginas de un libro. El método más obvio es dividir el disco virtual en grupos de sectores consecutivos del tamaño de los discos físicos individuales y almacenarlos de este modo, como coger un libro grande y romperlo en secciones pequeñas. Este método se llama _concatenación_ y tiene la ventaja de que los discos no requieren tener ninguna relación específica de tamaño entre ellos. Funciona bien cuando los accesos al disco virtual se reparten equitativamente en su espacio de direcciones. Cuando el acceso se concentra en un área más pequeña, la mejora es menos acentuada. <> ilustra una secuencia en la que las unidades de almacenamiento están asignadas en una organización concatenada. [[vinum-concat]] .Organización Concatenada image::vinum-concat.png[] Un mapeo alternativo es dividir el espacio de direcciones en componentes más pequeños del mismos tamaño y almacenarlos secuencialmente en distintos dispositivos. Por ejemplo, los primeros 256 sectores podrían ser almacenados en el primer disco, los 256 sectores siguientes en el siguiente disco, etc. Después de rellenar el último disco, el proceso se repite hasta que los discos están llenos. Este mapeo se llama _segmentado_ o `RAID-0`. `RAID` ofrece varias formas de tolerancia a fallos, aunque `RAID-0` es algo engañoso ya que no provee redundancia. El segmentado requiere algo más de esfuerzo para localizar el dato, y puede ocasionar carga de E/S adicional cuando una transferencia está repartida por múltiples discos, pero también puede proporcionar una carga más constante entre los discos. <> ilustra la secuencia en la que las unidades de discos están asignadas en una organización segmentada. [[vinum-striped]] .Organización Segmentada image::vinum-striped.png[] [[vinum-data-integrity]] == Integridad de los Datos El último problema con los discos es que no son fiables. Aunque la fiabilidad se ha incrementado tremendamente en los últimos años, las unidades de disco todavía son el componente central de un servidor más propensos a fallar. Cuando lo hacen, los resultados pueden ser catastróficas y reemplazar una unidad de disco que ha fallado y restaurar los datos puede resultar en tiempo de parada del servidor. Una aproximación a este problema es el _mirroring_, o `RAID-1`, que mantiene dos copias de los datos en distinto hardware físico. Cualquier escritura en el volumen escribe en ambos discos; una lectura puede ser resuelta por cualquiera, así que si un disco falla, los datos todavía están disponibles en la otra unidad. La configuración en espejo tiene dos problemas: * Requiere el doble de espacio de almacenamiento que una solución sin redundancia. * Las escrituras deben realizarse en las dos unidades, de forma que utilizan el doble de ancho de banda que un volumen sin espejo. Las lecturas no sufren penalización en lectura e incluso pueden ser más rápidas. Una solución alternativa es la _paridad_, implementada en los niveles `RAID` 2, 3, 4 y 5. De estos, `RAID-5` es el más interesante. Como está implementado en [.filename]#vinum#, es una variante en una organización segmentada que dedica un bloque en cada segmento para guardar la paridad de los otros bloques. Tal como está implementado en [.filename]#vinum#, un `RAID-5` plex es similar a un plex segmentado, excepto que implementa `RAID-5` al incluir un bloque de paridad en cada segmento. Según lo requerido por `RAID-5`, la localización de este bloque de paridad cambia de un segmento al siguiente. Los números en los bloques de datos indican los números de bloque relativos. [[vinum-raid5-org]] .Organización `RAID`-5 image::vinum-raid5-org.png[] Comparado con la configuración en espejo, `RAID-5` tiene la ventaja de que requiere mucho menos espacio de almacenamiento. El acceso de lectura es similar a una organización segmentada, pero el acceso de escritura es significativamente más lento, aproximadamente el 25% del rendimiento de lectura. Si una unidad falla, el array puede seguir operando en un modo degradado donde una lectura de una de las unidades que quedan accesibles continua normalmente, pero una lectura de una unidad que ha fallado es recalculada a partir de los bloques correspondientes del resto de unidades. [[vinum-objects]] == Objetos [.filename]#vinum# Para abordar estos problemas, [.filename]#vinum# implementa una jerarquía de objetos en cuatro niveles: * El objeto más visible es el disco virtual, llamado _volumen_. Volúmenes tienen esencialmente las mismas propiedades que una unidad de disco UNIX(R) aunque hay algunas pequeñas diferencias. Una de ellas, que no tienen limitación de tamaño. * Los volúmenes se componen de _plexes_, cada uno de los cuales representa el espacio de direcciones total de un volumen. Este nivel en la jerarquía proporciona redundancia. Piensa en los plexes como en discos individuales en un array replicado en espejo, cada uno conteniendo los mismos datos. * Puesto que [.filename]#vinum# existe dentro del framework de almacenamiento de disco de UNIX(R), sería posible utilizar particiones UNIX como bloques de construcción para plexes multi-disco. En realidad, esto resulta demasiado poco flexible ya que los discos UNIX sólo pueden tener un número limitado de particiones. En su lugar, [.filename]#vinum# subdivide una única partición UNIX, la _drive_, en areas contiguas llamadas _subdiscos_, los cuales se utilizan como bloques de construcción de plexes. * Los subdiscos residen en _unidades_ [.filename]#vinum#, actualmente particiones UNIX(R). Las unidades [.filename]#vinum# pueden tener cualquier número de subdiscos. Con la excepción de una pequeña área al comienzo de la unidad, que es utilizada para almacenar información de estado y configuración, la unidad entera está disponible para almacenamiento de datos. Las secciones siguientes describen el modo en el que estos objetos proporcionan la funcionalidad requerida por [.filename]#vinum#. === Consideraciones sobre el Tamaño del Volumen Plexes pueden incluir múltiples subdiscos repartidos por todas las unidades en la configuración de [.filename]#vinum#.. Como resultado, el tamaño de una unidad individual no limita el tamaño de un plex o un volumen. === Almacenamiento de Datos Redundante [.filename]#vinum#. implementa configuraciones en espejo adjuntando varios plexes a un volumen. Cada plex es una representación de los datos en un volumen. Un volumen puede contener entre uno y ocho plexes. Aunque un plex representa los datos completos de un volumen, es posible que algunas partes de esta representación falten físicamente, bien por diseño (no definiendo un subdisco para algunas partes del plex) o por accidente (como resultado del fallo de una unidad). Mientras un plex pueda proveer los datos para el rango completo de direcciones del volumen, este es plenamente funcional. === ¿Qué Organización Plex? [.filename]#vinum#. implementa tanto concatenación como segmentado a nivel de plex: * Un _plex concatenado_ usa el espacio de direcciones de cada subdisco por turnos. Los plexes concatenados son los más flexibles ya que pueden contener cualquier número de subdiscos, y los subidscos pueden ser de distintas longitudes. El plex se puede extender añadiendo subdiscos adicionales. Requieren menos tiempo de `CPU` que los plexes segmentados, aunque la diferencia en sobrecarga de `CPU` casi no se nota. Por otro lado, son más susceptibles a los puntos calientes, en donde un disco está muy activo y los otros ociosos. * Un _plex segmentado_ reparte los datos entre los distintos subdiscos. Los subdiscos deben tener todos el mismo tamaño y debe haber al menos dos subdiscos para poder distinguirlo de un plex concatenado. La mayor ventaja de los plexes segmentados es que reducen los puntos calientes. Escogiendo un tamaño óptimo de segmento, alrededor de 256 kB, la carga se puede repartir equitativamente entre las unidades. Extender un plex añadiendo nuevos subdiscos es tan complicado que [.filename]#vinum# no lo implementa. <> resume las ventajas y desventajas de cada organización plex. [[vinum-comparison]] .[.filename]#vinum# Organizaciones Plex [cols="1,1,1,1,1", frame="none", options="header"] |=== | Tipo de Plex | Subdiscos mínimos | Puede añadir subdiscos | Deben ser de igual tamaño | Aplicación |concatenado |1 |sí |no |Almacenamiento de muchos datos con máxima flexibilidad de colocación y rendimiento moderado |segmentado |2 |no |sí |Alto rendimiento combinado con un alto grado de acceso concurrente |=== [[vinum-examples]] == Algunos Ejemplos [.filename]#vinum# mantiene una _base de datos de configuración_ la cual describe los objetos que son conocidos a un sistema individual. Inicialmente, el usuario crea la base de datos de configuración a partir de uno o más ficheros de configuración utilizando man:gvinum[8]. [.filename]#vinum# almacena una copia de su base de datos de configuración en cada _dispositivo_ de disco bajo su control. Esta base de datos se actualiza con cada cambio de estado, de forma que un reinicio restablece de forma precisa el estado de cada objeto de [.filename]#vinum#. === El Fichero de Configuración El fichero de configuración describe objetos de [.filename]#vinum# individuales. La definición de un volumen sencillo podría ser: [.programlisting] .... drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a .... Este fichero describe cuatro objetos [.filename]#vinum#: * La línea _unidad_ describe una partición de disco (_unidad_) y su localización relativa al hardware que hay debajo. Se le da el nombre simbólico _a_. La separación entre los nombres simbólicos y los nombres de dispositivo permite mover discos de un lugar a otro sin confusión. * La línea _volumen_ describe un volumen. El único atributo requerido es el nombre, en este caso _myvol_. * La línea _plex_ define un plex. El único parámetro requerido es la organización, en este caso _concat_. El nombre no es necesario ya que el sistema genera uno automáticamente a partir del nombre del volumen añadiendo el sufijo _.px_, donde _x_ es el número del plex en el volumen. Por lo tanto este plex se llamará _myvol.p0_. * La línea _sd_ describe un subdisco. La especificación mínima incluye el nombre de la unidad en la que almacenarlo, y la longitud del subdisco. El nombre no es necesario ya que el sistema asigna un nombre automáticamente derivado del nombre del plex añadiendo el sufijo _.sx_, donde _x_ es el número del subdisco en el plex. Por lo tanto [.filename]#vinum# asigna a este subdisco el nombre _myvol.p0.s0_. Después de procesar este fichero, man:gvinum[8] produce la siguiente salida: [.programlisting] .... # gvinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB .... Esta salida muestra el formato de lista abreviada de man:gvinum[8]. Está representado gráficamente en <>. [[vinum-simple-vol]] .Un Volumen [.filename]#vinum# Simple image::vinum-simple-vol.png[] Esta imagen, y las que siguen, representa un volumen, el cual contiene plexes, que a su vez contienen subdiscos. En este ejemplo, el volumen contiene un plex, y el plex contiene un subdisco. Este volumen en particular no tiene ninguna ventaja sobre una partición de disco convencional. Contiene un solo plex, así que no es redundante. El plex contiene un solo subdisco, así que no hay diferencia en la asignación de almacenamiento respecto a una partición de disco convencional. Las siguientes secciones ilustran varios métodos de configuración más interesantes. === Resiliencia Incrementada: Configuración en Espejo La resiliencia de un volumen puede ser incrementada mediante una configuración en espejo. Cuando se diseña un volumen en espejo, es importante asegurar que los subdiscos de cada plex están en diferentes unidades, de forma que el fallo de una unidad no arrastre ambos plexes. La siguiente configuración crea un espejo de un volumen: [.programlisting] .... drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b .... En este ejemplo, no ha sido necesario especificar la definición de la unidad _a_ de nuevo, ya que [.filename]#vinum# hace un seguimiento de todos los objetos en su base de datos de configuración. Después de procesar esta definición, la configuración tiene este aspecto: [.programlisting] .... Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB .... <> muestra la estructura gráficamente. [[vinum-mirrored-vol]] .Un Volumen [.filename]#vinum# en Espejo image::vinum-mirrored-vol.png[] En este ejemplo, cada plex contiene los 512 MB del espacio de direcciones completo. Como en el ejemplo anterior, cada plex contiene solo un subdisco. === Optimizando el Rendimiento El volumen en espejo del ejemplo anterior es más resistente a fallos que un volumen que no esté en espejo, pero su rendimiento es menor ya que cada escritura en el volumen requiere una escritura en ambas unidades, usando una mayor porción del ancho de banda total del disco. Las consideraciones de rendimiento requieren una aproximación diferente: en lugar de replicar en espejo, los datos son segmentados en tantas unidades de disco como sea posible. La siguiente configuración muestra un volumen con un plex segmentado en cuatro discos: [.programlisting] .... drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d .... Como antes, no es necesario definir las unidades que ya son conocidas por [.filename]#vinum#. Después de procesar esta definición, la configuración tiene este aspecto: [.programlisting] .... Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB .... [[vinum-striped-vol]] .Un Volumen [.filename]#vinum# Segmentado image::vinum-striped-vol.png[] Este volumen está representado en <>. El color oscuro de los segmentos indican la posición dentro del espacio de direcciones del plex, donde los segmentos más claros aparecen primero y los más oscuros últimos. === Resiliencia y Rendimiento [[vinum-resilience]] Con suficiente hardware, es posible construir volúmenes que muestren resiliencia aumentada y rendimiento aumentado comparado con particiones UNIX(R) estándar. Una configuración típica podría ser: [.programlisting] .... volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b .... Los subdiscos del segundo plex están desplazados en dos unidades respecto a aquellos en el primer flex. Esto ayuda a garantizar que las escrituras no van al mismo subdisco incluso si la transferencia se realiza sobre dos unidades. <> representa la estructura de este volumen. [[vinum-raid10-vol]] .Un Volumen [.filename]#vinum# Segmentado en Espejo image::vinum-raid10-vol.png[] [[vinum-object-naming]] == Nombrado de Objetos [.filename]#vinum# asigna nombres por defecto a los plexes y los subdiscos, aunque pueden ser modificados. Modificar los nombres por defecto no está recomendado ya que no proporciona una ventaja significativa y puede provocar confusión. Los nombres pueden contener cualquier carácter que no sea blanco, pero se recomienda restringirlos a letras, dígitos y al carácter subrayado. Los nombres de los volúmenes, plexes y subdiscos pueden tener hasta 64 caracteres de longitud, y los nombres de unidades pueden ser de hasta 32 caracteres de longitud. A los objetos [.filename]#vinum# se les asignan nodos de dispositivo en la jerarquía [.filename]#/dev/gvinum#. La configuración que se muestra arriba haría que [.filename]#vinum# creara los siguientes nodos de dispositivo: * Entradas de dispositivo para cada volumen. Estos son los dispositivos principales utilizados por [.filename]#vinum#. La configuración anterior incluiría los dispositivos [.filename]#/dev/gvinum/myvol#, [.filename]#/dev/gvinum/mirror#, [.filename]#/dev/gvinum/striped#, [.filename]#/dev/gvinum/raid5# y [.filename]#/dev/gvinum/raid10#. * Todos los volúmenes tienen entradas directas bajo [.filename]#/dev/gvinum/#. * Los directorios [.filename]#/dev/gvinum/plex#, y [.filename]#/dev/gvinum/sd#, los cuales contienen nodos de dispositivo para cada plex y para cada subdisco, respectivamente. Por ejemplo, considera el siguiente fichero de configuración: [.programlisting] .... drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4 .... Después de procesar este fichero, man:gvinum[8] crea la siguiente estructura en [.filename]#/dev/gvinum#: [.programlisting] .... drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd /dev/vinum/plex: total 0 crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/sd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 .... Aunque se recomienda que los plexes y subdiscos no tengan asignados nombres específicos, las unidades de [.filename]#vinum# deben tener nombre. Esto hace posible mover una unidad a una localización diferente y que sea reconocida automáticamente. Los nombres de unidad pueden tener una longitud de hasta 32 caracteres. === Creando Sistemas de Ficheros En el sistema los volúmenes parecen idénticos a los discos, con una excepción. A diferencia de las unidades UNIX(R), [.filename]#vinum# no particiona los volúmenes, por lo que estos no tienen tabla de particiones. Esto ha requerido modificaciones en algunas utilidades de disco, notablemente de man:newfs[8], de forma que no intente interpretar la última letra de un nombre de volumen [.filename]#vinum#. Por ejemplo, una unidad de disco podría tener un nombre como /dev/ad0a# o /dev/da2h#. Estos nombres representan la primera partición ([.filename]#a#) en el primer (0) disco IDE ([.filename]#ad#) y la octava partición ([.filename]#h#) en el tercer (2) disco SCSI ([.filename]#da#) respectivamente. Por el contrario, un volumen [.filename]#vinum# podría llamarse /dev/gvinum/concat#, que no guarda relación con un nombre de partición. Para crear un sistema de ficheros en este volumen, usa man:newfs[8]: [source, shell] .... # newfs /dev/gvinum/concat .... [[vinum-config]] == Configurando [.filename]#vinum# El kernel [.filename]#GENERIC# no contiene [.filename]#vinum#. Es posible construir un kernel a medida que incluya [.filename]#vinum#, pero no se recomienda. La forma estándar de arrancar [.filename]#vinum# es como un módulo del kernel. man:kldload[8] no es necesario porque cuando man:gvinum[8] arranca, comprueba si el módulo ha sido cargado, y si no es así, lo carga automáticamente. === Arranque [.filename]#vinum# almacena información de configuración en las porciones de disco de forma esencialmente igual a como guarda los ficheros de configuración. Cuando lee de la base de datos de configuración, [.filename]#vinum# reconoce un número de palabras clave que no están permitidas en los ficheros de configuración. Por ejemplo, una configuración de disco podría contener el siguiente texto: [.programlisting] .... volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b .... Aquí las diferencias obvias son la presencia de información explícita de localización y nombrado, ambas permitidas pero no recomendadas, y la información de los estados. [.filename]#vinum# no almacena información sobre las unidades en la información de configuración. Encuentra las unidades escaneando las unidades de disco configuradas en busca de particiones con una etiqueta [.filename]#vinum#. Esto posibilita que [.filename]#vinum# identifique las unidades correctamente incluso si se les han asignado identificadores de unidad UNIX(R) diferentes. [[vinum-rc-startup]] ==== Arranque Automático _Gvinum_ siempre realiza un arranque automático una vez que el módulo del kernel ha sido cargado, via man:loader.conf[5]. Para cargar el módulo de _Gvinum_ en el arranque, añade `geom_vinum_load="YES"` a [.filename]#/boot/loader.conf#. Cuando [.filename]#vinum# es arrancado con `gvinum start`, [.filename]#vinum# lee la base de datos de configuración de una de las unidades [.filename]#vinum#. En condiciones normales, cada unidad contiene una copia idéntica de la base de datos de configuración, de forma que no importa de qué unidad se lea. Después de una caída, sin embargo, [.filename]#vinum# debe determinar qué unidad fue actualizada más recientemente y leer la configuración de esta unidad. Después actualiza la configuración progresivamente, si es necesario, de unidades más antiguas. [[vinum-root]] == Usando [.filename]#vinum# para el Sistema de Ficheros Raíz Para una máquina que tiene sistemas de ficheros completamente en espejo usando [.filename]#vinum#, es deseable también configurar en espejo el sistema de ficheros raíz. Establecer dicha configuración es menos trivial que configurar en espejo un sistema de ficheros arbitrario porque: * El sistema de ficheros raíz debe estar disponible muy temprano durante el proceso de arranque, por lo que la infraestructura [.filename]#vinum# debe estar disponible en ese momento. * El volumen que contiene el sistema de ficheros raíz, también contiene el sistema de arranque y el kernel. Estos deben ser leídos usando las utilidades nativas del sistema hospedador, como la BIOS, que frecuentemente no puede ser informada de los detalles de [.filename]#vinum#. En las secciones siguientes, el término "volumen raíz" se utiliza para describir el volumen [.filename]#vinum# que contiene el sistema de ficheros raíz. === Arrancando [.filename]#vinum# Suficientemente Pronto para el Sistema de Ficheros Raíz [.filename]#vinum# debe estar disponible pronto en el arranque del sistema puesto que man:loader[8] debe ser capaz de cargar el módulo del kernel de vinum antes de arrancar el kernel. Esto se puede conseguir poniendo la siguiente línea en [.filename]#/boot/loader.conf#: [.programlisting] .... geom_vinum_load="YES" .... === Haciendo Accesible un Volumen Raíz basado en [.filename]#vinum# en el Código de Arranque El código de arranque de FreeBSD ocupa sólo 7.5 KB y no entiende las estructuras internas de [.filename]#vinum#. Esto significa que no puede parsear los datos de configuración de [.filename]#vinum# o resolver los elementos de un volumen de arranque. Por lo tanto, se necesitan algunas soluciones alternativas para proporcionar al código de arranque con el espejismo de una partición estándar `a` que contiene el sistema de ficheros raíz. Para que esto sea posible, el volumen raíz debe cumplir los siguientes requisitos: * El volumen raíz no debe ser un segmento o `RAID`-5. * El volumen raíz no debe contener más de un subdisco concatenado por plex. Ten en cuenta que es deseable y posible utilizar múltiples plexes, cada uno conteniendo una réplica del sistema de ficheros raíz. El proceso de arranque sólo utilizará una réplica para encontrar el sistema de arranca y todos los ficheros de arranque, hasta que el kernel monta el sistema de ficheros raíz. Cada subdisco en estos plexes necesita su propio espejismo de partición `a`, para que el dispositivo respectivo sea arrancable. No es estrictamente necesario que cada una de estas particiones `a` simuladas estén localizadas en el mismo desplazamiento en el dispositivo, comparado con otros dispositivos que contienen plexes del volumen raíz. Sin embargo, probablemente sea buena idea crear volúmenes [.filename]#vinum# de ese modo de forma que los dispositivos en espejo sean simétricos, para evitar confusión. Para establecer estas particiones `a` para cada dispositivo que contiene una parte del volumen raíz, se necesite lo siguiente: [.procedure] ==== . La localización, desplazamiento desde el principio del dispositivo, y el tamaño del subdisco del dispositivo que forma parte del volumen raíz necesita ser examinado, usando el siguiente comando: + [source, shell] .... # gvinum l -rv root .... + Los desplazamientos y tamaños en [.filename]#vinum# se miden en bytes. Estos deben ser divididos entre 512 para obtener los números de bloque que van a ser usados por `bsdlabel`. . Ejecuta este comando para cada dispositivo que participa en el volumen raíz: + [source, shell] .... # bsdlabel -e devname .... + _devname_ debe ser o el nombre del disco, como [.filename]#da0# para discos sin una tabla de rebanadas, or el nombre de la rebanada, como [.filename]#ad0s1#. + Si ya hay en el dispositivo una partición a de un sistema raíz pre-[.filename]#vinum#>vinum#>, se debería renombrar a algo diferente de forma que se mantenga accesible (por si acaso), pero ya no será utilizado como arranque por defecto del sistema. Un sistema de ficheros raíz que está actualmente montado no puede ser renombrado, así que esto se debe ejecutar arrancando desde un medio "Fixit", o en un proceso de dos pasos donde, en una configuración en espejo, el disco que no está siendo arrancando es manipulado primero. + El desplazamiento de la partición [.filename]#vinum# en este dispositivo (si lo hay) se debe añadir al desplazamiento del subdisco del volumen raíz respectivo en este dispositivo.El valor resultante será el valor del `offset` para la nueva partición `a`. El valor de `size` para esta partición se tomará de forma literal del cálculo anterior. El `fstype` debería ser `4.2BSD`. Los valores `fsize`, `bsize`, y `cpg` deberían ser escogidos para que coincidan con el sistema de ficheros real, aunque no son realmente importantes en este contexto. + De ese modo, se establecerá una nueva partición `a` que solapa la partición [.filename]#vinum# en este dispositivo.`bsdlabel` solo permitirá este solapamiento si la partición [.filename]#vinum# ha sido adecuadamente marcada utilizando el fstype `vinum`. . Ahora existe una falsa partición `a` en cada dispositivo que tiene una réplica del volumen raíz. Es altamente recomendable verificar el resultado usando un comando como: + [source, shell] .... # fsck -n /dev/devnamea .... ==== Debería recordarse que todos los ficheros que contienen información de control deben ser relativos al sistema de ficheros raíz en el volumen [.filename]#vinum# que, cuando se establece un nuevo volumen raíz [.filename]#vinum#, podría no coincidir con el sistema de ficheros raíz que está actualmente activo. Así que en concreto, hay que tener cuidado con [.filename]#/etc/fstab# y [.filename]#/boot/loader.conf#. En el siguiente reinicio, el código de arranque debería averiguar la información de control apropiada en el nuevo sistema de ficheros raíz [.filename]#vinum#, y actuar en consecuencia. Al final del proceso de inicialización del kernel, después de que todos los dispositivos han sido anunciados, el aviso destacado que muestra el éxito de esta configuración es un mensaje como este: [source, shell] .... Mounting root from ufs:/dev/gvinum/root .... === Ejemplo de una Configuración Raíz basada en [.filename]#vinum# Después de que el volumen raíz [.filename]#vinum# ha sido configurado, la salida de `gvinum l -rv root` podría ser como: [source, shell] .... ... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB) .... Los valores en los que fijarse son `135680` para el offset, en relación a la partición /dev/da0h#. Esto se traduce en 256 bloques de disco de 512 bytes en términos de `bsdlabel`. De igual modo, el tamaño de este volumen raíz es 245760 bloques de 512 bytes. /dev/da1h#, al contener la segunda réplica de este volumen raíz, tiene una configuración asimétrica. El bsdlabel para estos dispositivos podría parecerse a: [source, shell] .... ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*) .... Se puede observar que el parámetro `size` para la partición falsa `a` coincide con el valor esbozado arriba, mientras que el parámetro `offset` es la suma del desplazamiento dentro de la partición [.filename]#vinum# `h`, y el desplazamiento de esta partición dentro del dispositivo o rebanada. Esta es una configuración típica que es necesaria para evitar el problema descrito en <>. La partición `a` entera está completamente dentro de la partición `h` que contiene todos los datos [.filename]#vinum# para este dispositivo. En el ejemplo de arriba, el dispositivo entero está dedicado a [.filename]#vinum# y no hay una partición raíz pre-[.filename]#vinum# restante. === Solución de problemas La siguiente lista contiene unos pocos problemas conocidos y sus soluciones. ==== El Sistema de Arranque Carga, pero el Sistema No Arranca Si por algún motivo el sistema con continúa con el arranque, el proceso de arranque se puede interrumpir presionando kbd:[espacio] durante el aviso de 10 segundos. La variable del cargador `vinum.autostart` puede examinarse tecleando `show` y manipularse usando `set` o `unset`. Si el módulo del kernel de [.filename]#vinum# no estaba en la lista de módulos que son cargados automáticamente, teclea `load geom_vinum`. Cuando está listo, el proceso de arranque puede continuar tecleando `boot -as` cuyo parámetro `-as` solicita al kernel que pregunte por el sistema de ficheros raíz a montar (`-a`) y hacer que el proceso de arranque pare en modo de usuario único (`-s`), donde el sistema de ficheros raíz está montado como solo lectura. De ese modo, incluso si sólo ha sido montado un plex de un volumen multi-plex, no hay riesgo de inconsistencia de datos entre plexes. En el prompt en el que se pregunta por el sistema de ficheros raíz a montar, se puede introducir cualquier dispositivo que contiene un sistema de ficheros raíz válido. Si [.filename]#/etc/fstab# está configurado correctamente, el valor por defecto debería ser algo como `ufs:/dev/gvinum/root`. Una opción alternativa típica sería algo como `ufs:da0d` que podría contener una hipotética partición de un sistema de ficheros raíz pre-[.filename]#vinum#. Ha que tener cuidado si se introduce uno de los alias de las particiones `a`, que en realidad referencia los subdiscos del dispositivo raíz [.filename]#vinum#, porque en una configuración en espejo, esto sólo montaría un trozo del dispositivo raíz en espejo. Si este sistema de ficheros se va a montar como lectura-escritura posteriormente, es necesario eliminar el otro plex(es) del volumen raíz [.filename]#vinum# puesto que de otro modo los plexes tendrían datos inconsistentes. ==== Sólo Arranca la Configuración de Arranque Primaria Si [.filename]#/boot/loader# falla al cargar, pero la configuración de arranque primaria todavía carga (visible mediante un sólo guión en la columna de la izquierda de la pantalla justo después de que comience el proceso de arranque), se puede intentar interrumpir el arranque primario presionando kbd:[espacio]. Esto hará que el proceso de arranque se pare en link:{handbook}#boot-boot1[stage two]. Aquí se puede intentar arrancar desde una partición alternativa, como la partición que contiene sl sistema de ficheros raíz anterior que ha sido movido desde `a`. [[vinum-root-panic]] ==== Nada Arranca, el Proceso de Arranque entra en Pánico Esta situación ocurrirá si el código de arranque ha sido destruido por la instalación de [.filename]#vinum#. Desafortunadamente, [.filename]#vinum# deja por accidente sólo 4KB libres al comienzo de su partición antes de empezar a escribir la información de cabecera de [.filename]#vinum#. Sin embargo, los códigos de arranque de las fases uno y dos más bsdlabel requieren 8 KB. Así que si una partición [.filename]#vinum# empezó en un offset 0 dentro de una rebanada o disco que se pretendía que fuera arrancable, la configuración de [.filename]#vinum# se llevará por delante el código de arranque. De forma similar, si se ha recuperado de la situación anterior, arrancando desde un medio "Fixit", y el código de arranque ha sido reinstalado utilizando `bsdlabel -B` como se describe en link:{handbook}#boot-boot1[stage two], el código de arranque destruirá la cabecera [.filename]#vinum#, y [.filename]#vinum# ya no podrá encontrar su(s) disco(s). Aunque ningún volumen [.filename]#vinum# o datos de configuración de [.filename]#vinum# serán destruidos, y sería posible recuperar todos los datos introduciendo de nuevo exactamente los mismos datos de configuración de [.filename]#vinum# la situación es difícil de arreglar. Es necesario mover la partición [.filename]#vinum# entera al menos 4 KB, para que la cabecera [.filename]#vinum# y el código de arranque del sistema ya no colisionen. diff --git a/documentation/content/pt-br/articles/vinum/_index.adoc b/documentation/content/pt-br/articles/vinum/_index.adoc index a1ee01695a..5d0589c670 100644 --- a/documentation/content/pt-br/articles/vinum/_index.adoc +++ b/documentation/content/pt-br/articles/vinum/_index.adoc @@ -1,579 +1,589 @@ --- title: O Gerenciador de Volume vinum authors: - author: Greg Lehey --- +//// +The Vinum Volume Manager +By Greg Lehey (grog at lemis dot com) + +Added to the Handbook by Hiten Pandya +and Tom Rhodes + +For the FreeBSD Documentation Project +//// + = O Gerenciador de Volume vinum :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Índice :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apêndice :table-caption: Tabela :figure-caption: Figura :example-caption: Exemplo ifeval::["{backend}" == "html5"] include::shared/pt-br/urls.adoc[] :imagesdir: ../../../images/articles/vinum/ endif::[] ifeval::["{backend}" == "pdf"] include::../../../../shared/pt-br/urls.adoc[] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] ifeval::["{backend}" == "epub3"] include::../../../../shared/pt-br/urls.adoc[] :imagesdir: ../../../../static/images/articles/vinum/ endif::[] ''' toc::[] [[vinum-synopsis]] == Sinopse Não importa o tipo de disco, sempre há problemas em potencial. Os discos podem ser muito pequenos, muito lentos ou pouco confiáveis para atender aos requisitos do sistema. Enquanto os discos estão ficando maiores, também ficam maiores os requisitos para armazenamento de dados. Geralmente, é necessário um sistema de arquivos maior que a capacidade de um disco. Várias soluções para esses problemas foram propostas e implementadas. Um método é através do uso de vários discos, e às vezes discos redundantes. Além de suportar várias placas e controladoras para sistemas `RAID` (Redundant Array of Independent Disks), o sistema básico do FreeBSD inclui o gerenciador de volumes [.filename]#vinum#, um driver de dispositivo de bloco que implementa discos virtuais e aborda esses três problemas. O [.filename]#vinum# oferece mais flexibilidade, desempenho e confiabilidade do que o armazenamento em disco tradicional e implementa os modelos `RAID`-0, `RAID`-1 e `RAID`-5, tanto individualmente quanto combinados. Este capítulo fornece uma visão geral dos possíveis problemas com o armazenamento em disco tradicional e uma introdução ao gerenciador de volumes [.filename]#vinum#. [NOTE] ==== Começando com o FreeBSD 5, o [.filename]#vinum# foi reescrito para se encaixar na link:{handbook}#geom[Arquitetura GEOM], mantendo as idéias originais, a terminologia e os metadados no disco. Esta reescrita é chamada _gvinum_ (para _GEOM vinum_). Enquanto este capítulo usa o termo [.filename]#vinum#, qualquer invocação de comandos deve ser executada com o `gvinum`. O nome do módulo do kernel mudou do original [.filename]#vinum.ko# para [.filename]#geom_vinum.ko#, e todos os device nodes residem em [.filename]#/dev/gvinum# em vez de [.filename]#/dev/vinum#. A partir do FreeBSD 6, a implementação original do [.filename]#vinum# não está mais disponível no código base. ==== [[vinum-access-bottlenecks]] == Gargalos de Acesso Sistemas modernos frequentemente precisam acessar dados de uma maneira altamente concorrente. Por exemplo, grandes servidores FTP ou HTTP podem manter milhares de sessões simultâneas e ter múltiplas conexões de 100 Mbit/s para o mundo externo, muito além da taxa de transferência sustentada da maioria dos discos. As unidades de disco atuais podem transferir dados sequencialmente a até 70 MB/s, mas esse valor é de pouca importância em um ambiente em que muitos processos independentes acessam uma unidade e onde podem obter apenas uma fração desses valores. Nesses casos, é mais interessante visualizar o problema do ponto de vista do subsistema de disco. O parâmetro importante é a carga que uma transferência coloca no subsistema ou o tempo pelo qual uma transferência ocupa as unidades envolvidas na transferência. Em qualquer transferência de disco, a unidade deve primeiro posicionar as cabeças, aguardar que o primeiro setor passe sob a cabeça de leitura e depois realizar a transferência. Essas ações podem ser consideradas atômicas, pois não faz sentido interrompê-las. [[vinum-latency]] Considere uma transferência típica de cerca de 10 kB: a geração atual de discos de alto desempenho pode posicionar as cabeças em uma média de 3,5 ms. As unidades mais rápidas giram a 15.000 rpm, portanto a latência rotacional média (meia revolução) é de 2 ms. A 70 MB/s, a própria transferência leva cerca de 150 μs, quase nada em comparação com o tempo de posicionamento. Nesse caso, a taxa de transferência efetiva cai para pouco mais de 1 MB/s e é claramente altamente dependente do tamanho da transferência. A solução tradicional e óbvia para esse gargalo é "mais eixos": em vez de usar um disco grande, use vários discos menores com o mesmo espaço de armazenamento agregado. Cada disco é capaz de se posicionar e transferir de forma independente, portanto, o rendimento efetivo aumenta em um fator próximo ao número de discos usados. A melhoria real da taxa de transferência é menor que o número de discos envolvidos. Embora cada unidade seja capaz de transferir em paralelo, não há como garantir que as solicitações sejam distribuídas uniformemente pelas unidades. Inevitavelmente, a carga em uma unidade será maior que em outra. A uniformidade da carga nos discos é fortemente dependente da maneira como os dados são compartilhados entre as unidades. Na discussão a seguir, é conveniente pensar no armazenamento em disco como um grande número de setores de dados que são endereçáveis por número, mais ou menos como as páginas de um livro. O método mais óbvio é dividir o disco virtual em grupos de setores consecutivos do tamanho dos discos físicos individuais e armazená-los dessa maneira, mais ou menos como pegar um livro grande e dividi-lo em seções menores. Esse método é chamado de _concatenação_ e tem a vantagem de os discos não precisarem ter nenhum relacionamento de tamanho específico. Ele funciona bem quando o acesso ao disco virtual é distribuído uniformemente sobre seu espaço de endereço. Quando o acesso é concentrado em uma área menor, a melhoria é menos acentuada. <> ilustra a seqüência na qual as unidades de armazenamento são alocadas em uma organização concatenada. [[vinum-concat]] .Organização Concatenada image::vinum-concat.png[] Um mapeamento alternativo é dividir o espaço de endereço em componentes menores e de tamanhos iguais e armazená-los sequencialmente em diferentes dispositivos. Por exemplo, os primeiros 256 setores podem ser armazenados no primeiro disco, os próximos 256 setores no próximo disco e assim por diante. Depois de preencher o último disco, o processo é repetido até que os discos estejam cheios. Este mapeamento é chamado _striping_ ou RAID-0. O `RAID` oferece várias formas de tolerância a falhas, embora o RAID-0 seja um pouco enganador, pois não fornece redundância. O striping requer um pouco mais de esforço para localizar os dados e pode causar carga de I/O (INPUT/OUTPUT) adicional, onde uma transferência é distribuída por vários discos, mas também pode fornecer uma carga mais constante nos discos. <> ilustra a seqüência na qual as unidades de armazenamento são alocadas em uma organização distribuída. [[vinum-striped]] .Organização do modo distribuido (Striped) image::vinum-striped.png[] [[vinum-data-integrity]] == Integridade de dados O problema final com os discos é que eles não são confiáveis. Embora a confiabilidade tenha aumentado tremendamente nos últimos anos, as unidades de disco ainda são o componente central mais provável de um servidor para falhar. Quando o fazem, os resultados podem ser catastróficos e substituir uma unidade de disco com falha e a restauração de dados pode resultar em tempo de inatividade do servidor. Uma abordagem para esse problema é o _mirroring (espelhamento)_, ou RAID-1, que mantém duas cópias dos dados em diferentes hardwares físicos. Qualquer gravação no volume grava em ambos os discos; uma leitura pode ser satisfeita de qualquer um, portanto, se uma unidade falhar, os dados ainda estarão disponíveis na outra unidade. O mirroring tem dois problemas: * Requer o dobro de armazenamento em disco que uma solução não redundante. * As gravações devem ser executadas em ambas as unidades, então ela usa o dobro da largura de banda de um volume não espelhado. As leituras não sofrem uma penalidade de desempenho e podem até ser mais rápidas. Uma solução alternativa é a _parity (paridade)_, implementada nos níveis `RAID` 2, 3, 4 e 5. Destes, o RAID-5 é o mais interessante. Como implementado no [.filename]#vinum#, é uma variante em uma organização striped que dedica um bloco de cada distribuição à paridade de um dos outros blocos. Como implementado por [.filename]#vinum#, um plex RAID-5 é semelhante a um plex striped, exceto que ele implementa RAID-5 incluindo um bloco de paridade em cada stripe. Conforme exigido pelo RAID-5, o local desse bloco de paridade muda de um stripe para o próximo. Os números nos blocos de dados indicam os números de blocos relativos. [[vinum-raid5-org]] .Organização `RAID`-5 image::vinum-raid5-org.png[] Comparado ao mirroring, o RAID-5 tem a vantagem de exigir significativamente menos espaço de armazenamento. O acesso de leitura é semelhante ao das organizações distribuídas, mas o acesso de gravação é significativamente mais lento, aproximadamente 25% do desempenho de leitura. Se uma unidade falhar, a matriz pode continuar a operar no modo degradado, onde uma leitura de uma das unidades acessíveis restantes continua normalmente, mas uma leitura da unidade com falha é recalculada a partir do bloco correspondente de todas as unidades restantes. [[vinum-objects]] == Objetos do [.filename]#vinum# A fim de resolver estes problemas, o [.filename]#vinum# implementa uma hierarquia de quatro níveis de objetos: * O objeto mais visível é o disco virtual, chamado _volume_. Os volumes têm essencialmente as mesmas propriedades de uma unidade de disco UNIX(R), embora haja algumas pequenas diferenças. Por um lado, eles não têm limitações de tamanho. * Os volumes são compostos de _plexes_, cada um dos quais representa o espaço de endereço total de um volume. Este nível na hierarquia fornece redundância. Pense em plexes como discos individuais em uma matriz espelhada, cada um contendo os mesmos dados. * Como o [.filename]#vinum# existe dentro do framework de armazenamento em disco UNIX(R), seria possível usar as partições UNIX(R) como bloco de construção para plexes de vários discos. Na verdade, isso acaba sendo muito inflexível, pois os discos UNIX(R) podem ter apenas um número limitado de partições. Em vez disso, o [.filename]#vinum# subdivide uma única partição UNIX(R), a _unidade_, em áreas contíguas chamadas _subdiscos_ , que são usados como blocos de construção para plexes. * Subdiscos residem em [.filename]#vinum# _drives_, atualmente partições UNIX(R). Unidades [.filename]#vinum# podem conter qualquer número de subdiscos. Com exceção de uma pequena área no início da unidade, que é usada para armazenar informações de configuração e estado, a unidade inteira está disponível para armazenamento de dados. As seções a seguir descrevem a maneira como esses objetos fornecem a funcionalidade necessária do [.filename]#vinum#. === Considerações sobre o tamanho do volume Os plexes podem incluir vários subdiscos distribuídos por todas as unidades na configuração [.filename]#vinum#. Como resultado, o tamanho de uma unidade individual não limita o tamanho de um plex ou de um volume. === Armazenamento de Dados Redundantes O [.filename]#vinum# implementa o espelhamento anexando vários plexes a um volume. Cada plex é uma representação dos dados em um volume. Um volume pode conter entre um e oito plexes. Embora um plex represente os dados completos de um volume, é possível que partes da representação estejam fisicamente ausentes, seja por design (por não definir um subdisco para partes do plex) ou por acidente (como resultado da falha de representação). Contanto que pelo menos um plex possa fornecer os dados para o intervalo de endereços completo do volume, o volume estará totalmente funcional. === Quais são as organizações disponíveis para um Plex? O [.filename]#vinum# implementa a concatenação e o striping no nível plex: * Um _plex concatenado_ usa o espaço de endereço de cada subdisco um de cada vez. Plexes concatenados são os mais flexíveis, pois podem conter qualquer número de subdiscos e os subdiscos podem ser de tamanho diferente. O plex pode ser estendido adicionando subdiscos adicionais. Eles exigem menos tempo de CPU do que os plexes distribuídos, embora a diferença na sobrecarga de CPU não seja mensurável. Por outro lado, eles são mais suscetíveis a hot spots, nos quais um disco é muito ativo e outros ficam ociosos. * Um _plex striped_ distribui os dados uniformemente entre cada subdisco. Os subdiscos devem ser todos do mesmo tamanho e deve haver pelo menos dois subdiscos para distingui-los de um plex concatenado. A maior vantagem dos plexes striped é que eles reduzem os hot spots. Ao escolher uma faixa de tamanho ideal, de cerca de 256 kB, a carga pode ser nivelada nas unidades de componentes. Estender um complexo adicionando novos subdiscos é algo tão complicado que o [.filename]#vinum# não o implementa. <> resume as vantagens e desvantagens de cada organização plex. [[vinum-comparison]] .Organizações Plex do [.filename]#vinum# [cols="1,1,1,1,1", frame="none", options="header"] |=== | Tipo plex | Subdiscos mínimos | Pode adicionar subdiscos | Deve ser de tamanho igual | Aplicação |concatenado |1 |sim |não |Armazenamento de dados grandes com flexibilidade máxima de posicionamento e desempenho moderado |striped |2 |não |sim |Alto desempenho em combinação com acesso altamente concorrente |=== [[vinum-examples]] == Alguns exemplos O [.filename]#vinum# mantém um _banco de dados de configuração_ que descreve os objetos conhecidos de um sistema individual. Inicialmente, o usuário cria o banco de dados de configuração a partir de um ou mais arquivos de configuração usando man:gvinum[8]. O [.filename]#vinum# armazena uma cópia de seu banco de dados de configuração em cada _dispositivo_ de disco sob seu controle. Este banco de dados é atualizado em cada mudança de estado, de modo que uma reinicialização restaura com precisão o estado de cada objeto [.filename]#vinum#. === O arquivo de configuração O arquivo de configuração descreve objetos [.filename]#vinum# individuais. A definição de um volume simples pode ser: [.programlisting] .... drive a device /dev/da3h volume myvol plex org concat sd length 512m drive a .... Este arquivo descreve quatro objetos [.filename]#vinum#: * A linha _drive_ descreve uma partição de disco (_drive_) e sua localização relativa ao hardware subjacente. É dado o nome simbólico _a_. Essa separação de nomes simbólicos de nomes de dispositivos permite que os discos sejam movidos de um local para outro sem confusão. * A linha _volume_ descreve um volume. O único atributo obrigatório é o nome, neste caso _myvol_. * A linha _plex_ define um plex. O único parâmetro requerido é a organização, neste caso _concat_. Nenhum nome é necessário, pois o sistema gera automaticamente um nome a partir do nome do volume, adicionando o sufixo _.px_, onde _x_ é o número de o plex no volume. Assim, este plex será chamado _myvol.p0_. * A linha _sd_ descreve um subdisco. As especificações mínimas são o nome de uma unidade na qual irá armazená-lo e o tamanho do subdisco. Nenhum nome é necessário porque o sistema atribui automaticamente nomes derivados do nome do plex adicionando o sufixo _.sx_, onde _x_ é o número do subdisco no plex. Assim, [.filename]#vinum# dá ao subdisco o nome _myvol.p0.s0_. Depois de processar este arquivo, o man:gvinum[8] produz a seguinte saída: [.programlisting] .... # gvinum -> create config1 Configuration summary Drives: 1 (4 configured) Volumes: 1 (4 configured) Plexes: 1 (8 configured) Subdisks: 1 (16 configured) D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB .... Esta saída mostra o formato de listagem breve de man:gvinum[8]. Ele está representado graficamente em <>. [[vinum-simple-vol]] .Um volume [.filename]#vinum# simples image::vinum-simple-vol.png[] Esta figura, e as que se seguem, representam um volume, que contém os plexes, que por sua vez contém os subdiscos. Neste exemplo, o volume contém um plex e o plex contém um subdisco. Este volume específico não tem nenhuma vantagem específica sobre uma partição de disco convencional. Ele contém um único plex, por isso não é redundante. O plex contém um único subdisco, portanto, não há diferença na alocação de armazenamento de uma partição de disco convencional. As seções a seguir ilustram vários métodos de configuração mais interessantes. === Maior Resiliência: Espelhamento A resiliência de um volume pode ser aumentada pelo espelhamento. Ao dispor um volume espelhado, é importante garantir que os subdiscos de cada plex estejam em unidades diferentes, de modo que uma falha no dispositivo não derrubará os dois plexes. A configuração a seguir espelha um volume: [.programlisting] .... drive b device /dev/da4h volume mirror plex org concat sd length 512m drive a plex org concat sd length 512m drive b .... Neste exemplo, não foi necessário especificar uma definição de drive _a_ novamente, já que o [.filename]#vinum# registra todos os objetos em seu banco de dados de configuração. Depois de processar esta definição, a configuração se parece com: [.programlisting] .... Drives: 2 (4 configured) Volumes: 2 (4 configured) Plexes: 3 (8 configured) Subdisks: 3 (16 configured) D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB .... <> mostra a estrutura graficamente. [[vinum-mirrored-vol]] .Um volume [.filename]#vinum# espelhado image::vinum-mirrored-vol.png[] Neste exemplo, cada plex contém os 512 MB completos do espaço de endereço. Como no exemplo anterior, cada plex contém apenas um único subdisco. === Otimizando o desempenho O volume espelhado no exemplo anterior é mais resistente a falhas do que um volume não espelhado, mas seu desempenho é menor, pois cada gravação no volume requer uma gravação nas duas unidades, utilizando uma grande parte da largura de banda total do disco. As considerações de desempenho exigem uma abordagem diferente: em vez de espelhar, os dados são distribuídos em quantas unidades de disco forem possíveis. A configuração a seguir mostra um volume com um plex distribuído em quatro unidades de disco: [.programlisting] .... drive c device /dev/da5h drive d device /dev/da6h volume stripe plex org striped 512k sd length 128m drive a sd length 128m drive b sd length 128m drive c sd length 128m drive d .... Como antes, não é necessário definir as unidades que já são conhecidas por [.filename]#vinum#. Depois de processar esta definição, a configuração se parece com: [.programlisting] .... Drives: 4 (4 configured) Volumes: 3 (4 configured) Plexes: 4 (8 configured) Subdisks: 7 (16 configured) D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) V myvol State: up Plexes: 1 Size: 512 MB V mirror State: up Plexes: 2 Size: 512 MB V striped State: up Plexes: 1 Size: 512 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p0 C State: up Subdisks: 1 Size: 512 MB P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB P striped.p1 State: up Subdisks: 1 Size: 512 MB S myvol.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p0.s0 State: up PO: 0 B Size: 512 MB S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB S striped.p0.s0 State: up PO: 0 B Size: 128 MB S striped.p0.s1 State: up PO: 512 kB Size: 128 MB S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB .... [[vinum-striped-vol]] .Um volume [.filename]#vinum# concatenado image::vinum-striped-vol.png[] Este volume é representado em <>. A escuridão das strips indica a posição dentro do espaço de endereço plex, onde as faixas mais claras vêm primeiro e as mais escuras por último. === Resiliência e Desempenho [[vinum-resilience]] Com hardware suficiente, é possível construir volumes que mostrem maior resiliência e melhor desempenho em comparação com as partições padrão UNIX(R). Um arquivo de configuração típico pode ser: [.programlisting] .... volume raid10 plex org striped 512k sd length 102480k drive a sd length 102480k drive b sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e plex org striped 512k sd length 102480k drive c sd length 102480k drive d sd length 102480k drive e sd length 102480k drive a sd length 102480k drive b .... Os subdiscos do segundo plex são compensados por duas unidades daquelas do primeiro plex. Isso ajuda a garantir que as gravações não vão para os mesmos subdiscos, mesmo que uma transferência passe por duas unidades. <> representa a estrutura deste volume. [[vinum-raid10-vol]] .Um volume [.filename]#vinum# espelhado e concatenado image::vinum-raid10-vol.png[] [[vinum-object-naming]] == Nomeação de Objetos O [.filename]#vinum# atribui nomes padrões a plexes e subdiscos, embora eles possam ser substituídos. Substituir os nomes padrões não é recomendado, pois não isso traz nenhuma vantagem significativa e pode causar confusão. Os nomes podem conter qualquer caractere não-branco, mas é recomendado restringi-los a letras, dígitos e caracteres de sublinhado. Os nomes de volumes, plexes e subdiscos podem ter até 64 caracteres e os nomes das unidades podem ter até 32 caracteres. Os objetos [.filename]#vinum# são designados a device nodes na hierarquia [.filename]#/dev/gvinum#. A configuração mostrada acima faria com que o [.filename]#vinum# criasse os seguintes device nodes: * Entradas de dispositivos para cada volume. Estes são os principais dispositivos usados pelo [.filename]#vinum#. A configuração acima incluiria os dispositivos [.filename]#/dev/gvinum/myvol#, [.filename]#/dev/gvinum/mirror#, [.filename]#/dev/gvinum/striped#, [.filename]#/dev/gvinum/raid5# e o [.filename]#/dev/gvinum/raid10#. * Todos os volumes recebem entradas diretas em [.filename]#/dev/gvinum/#. * Os diretórios [.filename]#/dev/gvinum/plex#, e [.filename]#/dev/gvinum/sd# são aqueles que contém device nodes para cada plex e para cada subdisco, respectivamente. Por exemplo, considere o seguinte arquivo de configuração: [.programlisting] .... drive drive1 device /dev/sd1h drive drive2 device /dev/sd2h drive drive3 device /dev/sd3h drive drive4 device /dev/sd4h volume s64 setupstate plex org striped 64k sd length 100m drive drive1 sd length 100m drive drive2 sd length 100m drive drive3 sd length 100m drive drive4 .... Depois de processar este arquivo, o man:gvinum[8] cria a seguinte estrutura em [.filename]#/dev/gvinum#: [.programlisting] .... drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd /dev/vinum/plex: total 0 crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 /dev/vinum/sd: total 0 crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 .... Embora seja recomendado que os plexes e subdiscos não sejam atribuídos a nomes específicos, as unidades [.filename]#vinum# devem ser nomeadas. Isso possibilita mover uma unidade para um local diferente e ainda reconhecê-la automaticamente. Os nomes dos drives podem ter até 32 caracteres. === Criando sistemas de arquivos Para o sistema os volumes são idênticos aos discos, com uma exceção. Ao contrário das unidades UNIX(R), o [.filename]#vinum# não particiona os volumes, e, portanto, não contêm uma tabela de partições. Isso exigiu modificação em alguns dos utilitários de disco, notavelmente no man:newfs[8], para que ele não tente interpretar a última letra de um nome do volume [.filename]#vinum# como um identificador de partição. Por exemplo, uma unidade de disco pode ter um nome como [.filename]#/dev/ad0a# ou [.filename]#/dev/da2h#. Esses nomes representam a primeira partição ([.filename]#a#) no primeiro (0) disco IDE ([.filename]#ad#) e a oitava partição ([.filename]#h#) no terceiro (2) disco SCSI ([.filename]#da#) respectivamente. Por outro lado, um volume [.filename]#vinum# pode ser chamado de [.filename]#/dev/gvinum/concat#, que não tem relação com o nome da partição. Para criar um sistema de arquivos neste volume, use man:newfs[8]: [source,shell] .... # newfs /dev/gvinum/concat .... [[vinum-config]] == Configurando o [.filename]#vinum# O kernel [.filename]#GENERIC# não suporta o [.filename]#vinum#. É possível compilar um kernel customizado que inclua o suporte estático ao [.filename]#vinum#, mas isso não é recomendado. A maneira padrão de iniciar o [.filename]#vinum# é como um módulo do kernel. O uso do man:kldload[8] não é necessário porque quando o man:gvinum[8] é iniciado, ele verifica se o módulo já foi carregado e, se ele não tiver sido, ele será carregado automaticamente. === Começando O [.filename]#vinum# armazena as informações de configuração nos slices dos discos essencialmente da mesma forma que nos arquivos de configuração. Ao ler a partir do banco de dados de configuração, o [.filename]#vinum# reconhece um número de palavras-chave que não são permitidas nos arquivos de configuração. Por exemplo, uma configuração de disco pode conter o seguinte texto: [.programlisting] .... volume myvol state up volume bigraid state down plex name myvol.p0 state up org concat vol myvol plex name myvol.p1 state up org concat vol myvol plex name myvol.p2 state init org striped 512b vol myvol plex name bigraid.p0 state initializing org raid5 512b vol bigraid sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b .... As diferenças óbvias aqui são a presença de informações explícitas de localização e nomeação, as quais são ambas permitidas mas desencorajadas, e as informações sobre os estados. O [.filename]#vinum# não armazena informações sobre unidades nas informações de configuração. Ele encontra as unidades varrendo as unidades de disco configuradas em busca de partições com um rótulo [.filename]#vinum#. Isso permite que o [.filename]#vinum# identifique as unidades corretamente, mesmo que elas tenham recebido diferentes IDs de unidade UNIX(R). [[vinum-rc-startup]] ==== Inicialização automática O _Gvinum_ apresenta sempre uma inicialização automática assim que o módulo do kernel é carregado, através do man:loader.conf[5]. Para carregar o módulo _Gvinum_ no momento da inicialização, adicione `geom_vinum_load="YES"` ao arquivo [.filename]#/boot/loader.conf#. Quando o [.filename]#vinum# é iniciado com `gvinum start`, o [.filename]#vinum# lê o banco de dados de configuração de uma das unidades [.filename]#vinum#. Em circunstâncias normais, cada unidade contém uma cópia idêntica do banco de dados de configuração, portanto, não importa qual unidade é lida. Após uma falha, no entanto, o [.filename]#vinum# deve determinar qual unidade foi atualizada mais recentemente e ler a configuração desta unidade. Em seguida, atualiza a configuração, se necessário, de unidades progressivamente a partir das mais antigas. [[vinum-root]] == Usando o [.filename]#vinum# para o sistema de arquivos raiz Para uma máquina que tenha sistemas de arquivos totalmente espelhados usando [.filename]#vinum#, é desejável também espelhar o sistema de arquivos raiz. Efetuar esta configuração é menos trivial do que espelhar um sistema de arquivos arbitrário porque: * O sistema de arquivos raiz deve estar disponível muito cedo durante o processo de inicialização, portanto a infraestrutura [.filename]#vinum# já deve estar disponível no momento. * O volume que contém o sistema de arquivos raiz também contém a auto-inicialização do sistema e o kernel. Eles devem ser lidos usando os utilitários nativos do sistema, como o BIOS, que muitas vezes não pode ser instruído sobre os detalhes do [.filename]#vinum#. Nas seções a seguir, o termo "volume raiz" é geralmente usado para descrever o volume [.filename]#vinum# que contém o sistema de arquivos raiz (/). === Iniciando o [.filename]#vinum# cedo o suficiente para o sistema de arquivos raiz O [.filename]#vinum# deve estar disponível no início da inicialização do sistema pois o man:loader[8] deve ser capaz de carregar o módulo do kernel vinum antes de iniciar o kernel. Isto pode ser feito colocando esta linha no [.filename]#/boot/loader.conf#: [.programlisting] .... geom_vinum_load="YES" .... === Tornando um volume raiz baseado em [.filename]#vinum# acessível ao Bootstrap O bootstrap atual do FreeBSD tem apenas 7.5 KB de código e não entende as estruturas internas do [.filename]#vinum#. Isso significa que não é possível analisar os dados de configuração [.filename]#vinum# ou descobrir os elementos de um volume de inicialização. Assim, algumas soluções alternativas são necessárias para fornecer ao código de inicialização a ilusão de que ele está trabalhando com uma partição padrão `a` que contém o sistema de arquivos raiz. Para que isso seja possível, os seguintes requisitos devem ser atendidos para o volume raiz: * O volume raiz não pode ser uma stripe ou `RAID` -5. * O volume raiz não deve conter mais de um subdisco concatenado por plex. Observe que é desejável e possível usar vários plexes, cada um contendo uma réplica do sistema de arquivos raiz. O processo de bootstrap usará apenas uma réplica para localizar o bootstrap e todos os arquivos de inicialização, até que o kernel monte o sistema de arquivos raiz. Cada subdisco dentro desses plexes precisa da sua própria ilusão de partição `a`, para que o respectivo dispositivo seja inicializável. Não é estritamente necessário que cada uma dessas falsas partições `a` estejam localizadas no mesmo deslocamento dentro de seu dispositivo, em comparação com outros dispositivos contendo plexes do volume raiz. No entanto, é provavelmente uma boa ideia criar os volumes [.filename]#vinum# dessa forma para que os dispositivos espelhados resultantes sejam simétricos, para evitar confusão. Para configurar essas partições `a` para cada dispositivo contendo parte do volume raiz, é necessário o seguinte: [.procedure] . A localização, offset desde o início do dispositivo, e o tamanho do subdisco desse dispositivo que faz parte do volume raiz precisam ser examinados, usando o comando: + [source,shell] .... # gvinum l -rv root .... + Os offsets (deslocamentos) e tamanhos do [.filename]#vinum# são medidos em bytes. Eles devem ser divididos por 512 para obter os números de blocos que serão usados pelo `bsdlabel`. . Execute este comando para cada dispositivo que participa do volume raiz: + [source,shell] .... # bsdlabel -e devname .... + No comando acima _devname_ deve ser o nome do disco, como [.filename]#da0# para discos sem uma tabela de slices, ou o nome da slice, como [.filename]#ad0s1#. + Se já existir uma partição `a` no dispositivo a partir de um sistema de arquivos raiz pré-[.filename]#vinum#, ela deve ser renomeada para outra coisa para que permaneça acessível (apenas nesse caso), mas ela não será mais usada por padrão para inicializar o sistema. Um sistema de arquivos raiz atualmente montado não pode ser renomeado, portanto, de forma que o processo ser executado quando o sistema for inicializado a partir de uma mídia "Fixit" ou em um processo de duas etapas em que, em um espelho, o disco que ainda não foi inicializado é manipulado primeiro. + O offset da partição [.filename]#vinum# neste dispositivo (se houver) deve ser adicionado ao deslocamento do respectivo subdisco de volume raiz neste dispositivo. O valor resultante se tornará o valor do `offset` para a nova partição `a`. O valor do `size` para esta partição também pode ser obtido a partir do cálculo acima. O `fstype` deve ser `4.2BSD`. Os valores de `fsize`, `bsize` e `cpg` devem ser escolhidos para corresponder ao sistema de arquivos atual, embora eles sejam relativamente sem importância dentro deste contexto. + Desta forma, uma nova partição `a` será estabelecida sobrepondo a partição [.filename]#vinum# neste dispositivo. O `bsdlabel` só permitirá essa sobreposição se a partição [.filename]#vinum# tiver sido marcada corretamente usando o modo fstype do `vinum`. . Temos agora uma falsa partição `a` em cada dispositivo que possui uma réplica do volume raiz. É altamente recomendável verificar o resultado usando um comando como: + [source,shell] .... # fsck -n /dev/devnamea .... Deve ser lembrado que todos os arquivos contendo informações de controle devem ser relativos ao sistema de arquivos raiz no volume [.filename]#vinum# e que, ao configurarmos um novo volume raiz [.filename]#vinum#, ele pode não corresponder o sistema de arquivos raiz que está atualmente ativo. Então, em particular, o [.filename]#/etc/fstab# e [.filename]#/boot/loader.conf# precisam ser ajustados. Na próxima reinicialização, o bootstrap deve descobrir as informações de controle apropriadas do novo sistema de arquivos raiz baseado no [.filename]#vinum# e agir de acordo. No final do processo de inicialização do kernel, após todos os dispositivos terem sido anunciados, o aviso de destaque que mostra o sucesso desta configuração é uma mensagem como: [source,shell] .... Mounting root from ufs:/dev/gvinum/root .... === Exemplo de uma configuração raiz baseada em [.filename]#vinum# Depois que o volume raiz [.filename]#vinum# foi configurado, a saída de `gvinum l -rv root` pode parecer com: [source,shell] .... ... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB) .... Os valores a serem observados são `135680` para o offset, relativo à partição [.filename]#/dev/da0h#. Isso se traduz em 265 blocos de discos de 512 bytes nos termos do `bsdlabel`. Da mesma forma, o tamanho desse volume raiz é de 245760 blocos de 512 bytes. O [.filename]#/dev/da1h#, contém a segunda réplica deste volume raiz, e possui uma configuração simétrica. O bsdlabel para esses dispositivos pode se parecer com: [source,shell] .... ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*) .... Pode-se observar que o parâmetro `size` para a falsa partição `a` corresponde ao valor descrito acima, enquanto o parâmetro `offset` é a soma do deslocamento dentro da partição [.filename]#vinum#`h`, e o offset desta partição dentro do dispositivo ou slice. Esta é uma configuração típica que é necessária para evitar o problema descrito em <>. A partição `a` inteira está completamente dentro da partição `h` que contém todos os dados [.filename]#vinum# para este dispositivo. No exemplo acima, todo o dispositivo é dedicado ao [.filename]#vinum# e não há sobra de partição raiz pré-[.filename]#vinum#. === Soluções de problemas A lista a seguir contém algumas armadilhas e soluções conhecidas. ==== Sistema de bootstrap carrega, mas o sistema não Se por algum motivo o sistema não continuar a inicialização, o bootstrap pode ser interrompido pressionando kbd:[espaço] no aviso de 10 segundos. A variável `vinum.autostart` do loader pode ser examinada digitando `show` e manipulada usando `set` ou `unset`. Se o módulo do kernel [.filename]#vinum# ainda não estava na lista de módulos para carregar automaticamente, digite `load geom_vinum`. Quando estiver pronto, o processo de inicialização pode ser continuado digitando-se `boot -as`, no qual `-as` solicita ao kernel que peça ao sistema de arquivos raiz para montar (`-a`) e fazer com que o processo de inicialização pare no modo single user(`-s`), em que o sistema de arquivos raiz é montado como somente leitura. Dessa forma, mesmo que apenas um plex de um volume multi-plex tenha sido montado, não estaremos arriscando nenhuma inconsistência de dados entre os plexes. No prompt solicitando que um sistema de arquivos raiz seja montado, qualquer dispositivo que contenha um sistema de arquivos raiz válido pode ser inserido. Se o [.filename]#/etc/fstab# estiver configurado corretamente, o padrão deve ser algo como `ufs:/dev/gvinum/root`. Uma opção alternativa típica seria algo como `ufs:da0d`, que poderia ser uma partição hipotética contendo o sistema de arquivos raiz pré-[.filename]#vinum#. Deve-se tomar cuidado se uma das partições alias `a` for inserida aqui, para verificar se ela realmente faz referência aos subdiscos do dispositivo raiz [.filename]#vinum#, porque em uma configuração espelhada, isso apenas montaria uma parte de um dispositivo raiz espelhado. Se este sistema de arquivos tiver que ser montado no modo read-write mais tarde, será necessário remover o(s) outro(s) plex(es) do volume raiz [.filename]#vinum#, já que esses plexes carregariam dados inconsistentes. ==== Apenas o bootstrap primário carrega Se o [.filename]#/boot/loader# falhar ao carregar, mas o bootstrap primário ainda carregar (visível por um único traço na coluna esquerda da tela logo após o processo de boot ser iniciado), uma tentativa pode ser feita para interromper o bootstrap primário pressionando kbd:[espaço]. Isso fará com que o bootstrap pare no link:{handbook}#boot-boot1[estágio dois]. Uma tentativa pode ser feita aqui para inicializar uma partição alternativa, como a partição que contém o sistema de arquivos raiz anterior que foi movido de `a`. [[vinum-root-panic]] ==== Nada carrega e o Bootstrap entra em panic Esta situação acontecerá se o bootstrap tiver sido destruído pela instalação do [.filename]#vinum#. Infelizmente, o [.filename]#vinum# acidentalmente deixa apenas 4 KB no início de sua partição livre antes de começar a escrever suas informações de cabeçalho [.filename]#vinum#. No entanto, o estágio um e dois bootstraps mais o bsdlabel exigem 8 KB. Portanto, se uma partição [.filename]#vinum# tiver sido iniciada no offset 0 dentro de uma slice ou disco que deveria ser inicializável, a configuração do [.filename]#vinum# irá estragar o bootstrap. Da mesma forma, se a situação acima foi recuperada, inicializando de uma mídia "Fixit", e o bootstrap foi reinstalado usando `bsdlabel -B` como descrito em link:{handbook}#boot-boot1[Estágio Um e Estágio Dois], o bootstrap irá estragar o cabeçalho [.filename]#vinum# e o [.filename]#vinum# não encontrará mais seu(s) disco(s). Entretando nenhum dado de configuração real do [.filename]#vinum# e nenhum volume [.filename]#vinum# de dados foi descartado, sendo possível recuperá-los digitando de novo exatamente as mesmas configurações do [.filename]#vinum#, a situação é difícil de corrigir de forma definitiva. Pois será necessário mover toda a partição [.filename]#vinum# em pelo menos 4 KB, para que o cabeçalho [.filename]#vinum# e o bootstrap do sistema não colidam mais.