0 - en to fa-IR translation catalogue (320 entries)

en: Monitoring
fa-IR: مانیتورینگ

en: Virtualization
fa-IR: مجازی‌سازی

en: Advanced Administration
fa-IR: مدیریت پیشرفته

en: This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.
fa-IR: این فصل به مرور مفاهیمی که تاکنون به آن‌ها پرداخته‌ایم می‌پردازد، اما با رویکردی متفاوت: بجای نصب یک رایانه تکی، به مطالعه نصب-انبوه روی سیستم‌ها می‌پردازیم؛ بجای نصب RAID یا LVM در زمان نصب، اینکار را به صورت دستی در زمان دیگری که نیاز داشته باشیم انجام می‌دهیم. در نهایت، درباره ابزارهای مانیتورینگ و تکنیک‌های مجازی‌سازی صحبت خواهیم کرد. به همین دلیل، مخاطب این فصل روی مدیرسیستم‌های حرفه‌ای تمرکز دارد و به جنبه‌های شخصی و انفرادی این کار کمتر توجه می‌کند.

en: RAID and LVM
fa-IR: RAID و LVM

en: <emphasis>PERSPECTIVE</emphasis> Btrfs combines LVM and RAID
fa-IR: <emphasis>چشم‌انداز</emphasis> ترکیب RAID و LVM در Btrfs

en: Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.
fa-IR: از میان ویژگی‌های آن، توانایی ایجاد snapshot از فایل‌سیستم در هر لحظه از زمان وجود دارد. این رونوشت از snapshot به صورت اولیه هیچ فضایی را اشغال نمی‌کند، داده زمانی تکرار می‌شود که یکی از این رونوشت‌ها تغییر کند. فایل‌سیستم همچنین از فشرده‌سازی شفاف فایل‌ها پشتیبانی و از checksum برای اطمینان از جامعیت داده‌های ذخیره شده استفاده می‌کند.

en: In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.
fa-IR: در هر دو مورد RAID  و LVM، کرنل یک دستگاه بلاک-محور فراهم می‌کند، مشابه آن‌هایی که برای درایو هارد دیسک یا یک پارتیشن بکار می‌رود. زمانی که یک برنامه، یا قسمتی از کرنل، درخواست دسترسی به چنین دستگاهی را داشته باشد، زیرسیستم مرتبط با آن فرآیند مسیریابی بلاک به لایه فیزیکی مرتبط را برقرار می‌کند. با توجه به پیکربندی، این بلاک می‌تواند در یک یا چند دیسک فیزیکی ذخیره شده باشد و مکان فیزیکی آن ممکن است به صورت مستقیم مرتبط با مکان بلاک در دستگاه مجازی نباشد.

en: Software RAID
fa-IR: RAID نرم‌افزاری

en: <emphasis>CULTURE</emphasis> <foreignphrase>Independent</foreignphrase> or <foreignphrase>inexpensive</foreignphrase>?
fa-IR: <emphasis>فرهنگ</emphasis> <foreignphrase>مستقل</foreignphrase> یا <foreignphrase>ارزان</foreignphrase>؟

en: RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.
fa-IR: RAID می‌تواند هم به صورت سخت‌‌افزاری (افزونه‌های RAID منطبق با کارت‌های کنترل SCSI یا SATA) هم به صورت نرم‌افزاری (توسط کرنل) پیاده‌سازی شود. جدا از شیوه پیاده‌سازی آن، یک سیستم RAID در صورت وجود افزونگی کافی می‌تواند در زمان بروز نقص دیسک به کار خود ادامه دهد؛ لایه‌های بالایی آن (برنامه‌ها) حتی می‌توانند در صورت بروز مشکل به داده دسترسی داشته باشند. البته که این “حالت ناامن” می‌تواند عملکرد منفی روی سیستم بگذارد و منجر به کاهش سطح افزونگی گردد، بنابراین یک نقص دیسک دیگر، منجر به از دست دادن داده می‌شود. در عمل، تنها یک دیسک تلاش می‌کند که در این حالت تخریبی تا زمان برطرف شدن مشکل قرار بگیرد. زمانی که دیسک جدید جایگزین شود، سیستم RAID می‌تواند با بازسازی داده به حالت امن خود بازگردد. زمانی که آرایه در حالت ناامن یا فاز بازسازی داده قرار می‌گیرد، عملا وقفه‌ای در برنامه‌ها ایجاد نمی‌گردد بجز کاهش سرعت دسترسی به داده.

en: When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).
fa-IR: زمانی که RAID به صورت سخت‌افزاری پیاده‌سازی شود، پیکربندی آن درون ابزار برپایی BIOS قرار می‌گیرد و کرنل یک آرایه RAID را به عنوان یک دیسک مجزا در نظر می‌گیرد، که مانند یک دیسک استاندارد کار خواهد کرد، با این حال نام دستگاه می‌تواند متفاوت باشد (بر اساس درایو بکار رفته).

en: We only focus on software RAID in this book.
fa-IR: ما تنها به RAID نرم‌افزاری در این کتاب اشاره می‌کنیم.

en: Different RAID Levels
fa-IR: سطوح مختلف RAID

en: RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.
fa-IR: RAID در حقیقت یک سیستم مجزا نیست، بلکه بازه‌ای از سیستم‌ها در سطوح مختلف است؛ این سطوح با توجه به ساختار و میزان افزونگی داده با یکدیگر فرق دارند. هر چه افزونگی بیشتر باشد، توانایی مواجه به دیسک‌های خراب در زمان نقص سخت‌افزاری بالاتر می‌رود. نقطه مقابل آن زمانی است که فضای موجود برای مجموعه‌ای از دیسک‌ها کاهش یابد؛ که در این صورت به دیسک‌های بیشتری برای ذخیره‌سازی داده نیاز است.

en: Linear RAID
fa-IR: RAID خطی

en: This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in <emphasis>stripes</emphasis>, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.
fa-IR: این سطح نیز هیچ افزونگی داده‌ای را فراهم نمی‌کند ولی برخلاف سطح قبل دیسک‌ها به صورت پیوسته پشت سر هم قرار نمی‌گیرند: بلکه به <emphasis>stripes</emphasis> تقسیم می‌شوند و بلاک‌های دستگاه مجازی روی این stripe از دیسک‌های فیزیکی قرار می‌گیرند. برای نمونه، در یک تنظیم RAID-0 با دو دیسک، بلاک‌های شماره زوج از دستگاه مجازی روی دیسک فیزیکی اول و بلاک‌های شماره فرد روی دیسک فیزیکی دوم ذخیره می‌شوند.

en: This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.
fa-IR: این سطح، که با نام “RAID Mirroring” نیز شناخته می‌شود، ساده‌ترین و پرکاربردترین تنظیم مورد استفاده است. در حالت استاندارد، از دو دیسک فیزیکی هم اندازه استفاده می‌کند تا یک فضای منطقی به همان اندازه را فراهم کند. داده به صورت کاملا یکسان روی هر دو دیسک ذخیره می‌شود، که همان عبارت “mirror” است. زمانی که یک دیسک خراب شود داده از دیسک دیگر قابل دسترس است. برای داده‌های بسیار حیاتی، RAID-1 می‌تواند با بیش از دو دیسک تنظیم شود، که تاثیر مستقیم روی نرخ هزینه سخت‌افزار در مقابل فضای موجود خواهد گذاشت.

en: <emphasis>NOTE</emphasis> Disks and cluster sizes
fa-IR: <emphasis>یادداشت</emphasis> دیسک‌ها و اندازه‌های خوشه

en: If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.
fa-IR: اگر دو دیسک با اندازه مختلف در این سطح بکار گرفته شوند، از دیسک بزرگ‌تر به طور کامل استفاده نخواهد شد چرا که تنها شامل تمام داده‌های دیسک کوچک‌تر است. بنابراین فضای قابل استفاده در یک تنظیم RAID-1 برابر با کوچک‌ترین دیسک موجود در آرایه است. این الگو در رابطه با سایر سطوح RAID پیشرفته‌تر نیز صادق است، با اینکه ممکن است از فرآیند افزونگی دیگری استفاده کنند.

en: It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.
fa-IR: به همین دلیل، مهم است که در زمان برپایی آرایه‌های RAID (بجز RAID-0 و خطی) از دیسک‌های با اندازه مشابه یا بسیار نزدیک به هم استفاده شود تا هیچ فضای اضافی تلف نگردد.

en: <emphasis>NOTE</emphasis> Spare disks
fa-IR: <emphasis>یادداشت</emphasis> دیسک‌های کمکی

en: RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.
fa-IR: سطوح RAID که شامل افزونگی داده هستند اجازه استفاده از دیسک‌های بیشتر در آرایه دیسک‌ها را فراهم می‌کنند. از این دیسک‌ها به منظور پشتیبان در زمان بروز نقص برای یکی از دیسک‌های موجود استفاده می‌شود. برای نمونه، در یک تنظیم دو دیسکه همراه با دیسک کمکی، اگر یکی از دیسک‌های اولیه معیوب شود، کرنل به صورت خودکار (و بلافاصله) فضای موجود را با استفاده از دیسک کمکی بازسازی می‌کند، به منظور اینکه اطمینان از عملیات افزونگی داده پس از زمان بازسازی حاصل گردد. از این روش می‌توان به عنوان گام اضافه برای نگهداری از داده‌های بسیار حساس استفاده کرد.

en: One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.
fa-IR: ممکن است به نظر آید که چطور این پیکربندی در مقایسه با استفاده از سه دیسک برای mirroring ممکن است مفید باشد. مزیت استفاده از پیکربندی “دیسک کمکی” این است که می‌تواند بین چندین فضای ذخیره‌سازی RAID به اشتراک گذاشته شود. برای نمونه، می‌توان از سه فضای ذخیره‌سازی mirrored استفاده کرد، همراه با افزونگی داده که در صورت بروز نقص در یکی از دیسک‌ها بکار می‌آید، همراه با هفت دیسک (سه زوج به همراه یک دیسک کمکی) بجای نه دیسک که مورد نیاز سه خانواده سه زوجی است.

en: This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.
fa-IR: این سطح RAID، با وجود هزینه بالا (از آنجا که در بهترین حالت از نصف فضای ذخیره‌سازی استفاده می‌شود) در عمل بسیار مورد استفاده قرار می‌گیرد. درک آن بسیار ساده است و امکان ایجاد پشتیبان‌های ساده وجود دارد: از آنجا که هر دو دیسک شامل محتوای یکسانی هستند، یکی از آن‌ها بدون ایجاد کوچکترین تاثیر منفی روی سیستم می‌تواند تخلیه شود. عملیات خواندن نیز بسیار سریع‌تر خواهد بود چرا که در هر لحظه کرنل به صورت همزمان نصف داده را از هر دو دیسک می‌تواند بخواند، با اینکه عملیات نوشتن آنطور که به نظر می‌آید تاثیر منفی ندارد. در مورد آرایه RAID-1 از N دیسک، حتی در صورت معیوب شدن N-1 دیسک داده کماکان قابل دسترس خواهد بود.

en: This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.
fa-IR: این سطح RAID، که کاربرد زیادی ندارد، از N دیسک برای ذخیره‌سازی داده مفید و از یک دیسک اضافی برای ذخیره‌سازی اطلاعات افزونگی استفاده می‌کند. اگر این دیسک اضافی معیوب شود، سیستم می‌تواند با آن N دیسک دیگر محتوای خود را بازسازی کند، به صورتی که N-1 دیسک باقیمانده همراه با دیسک “parity” شامل اطلاعات کافی برای بازسازی تمام اطلاعات هستند.

en: RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).
fa-IR: RAID-4 هزینه زیادی ندارد چرا که تنها شامل یک هزینه افزایشی یک در N می‌باشد که تاثیر بسزایی روی عملیات خواندن ندارد ولی عملیات نوشتن را کند می‌کند. علاوه بر این، از آنجا که نوشتن روی هر یک از N دیسک به معنای نوشتن روی دیسک parity است، این دیسک اضافی شاهد نوشتن‌های بیشتری نسبت به سایر دیسک‌ها است و همین دلیل نیز باعث کاهش طول عمر مفید آن می‌گردد. داده روی آرایه RAID-4 تنها در صورت معیوب شدن یک دیسک از N+1 دیسک موجود ایمن خواهد بود.

en: RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.
fa-IR: RAID-5 مشکل عدم تقارن در RAID-4 را برطرف می‌کند: بلاک‌های parity بین تمام N+1 دیسک دیگر پخش می‌شوند به صورتی که تنها یک دیسک نقش منحصربفرد نداشته باشد.

en: Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.
fa-IR: عملیات خواندن و نوشتن درست مانند  RAID-4 است. در اینجا نیز، سیستم تا زمانی بکار خود ادامه می‌دهد که تنها یک دیسک معیوب از N+1 دیسک موجود باشد ولی نه بیشتر.

en: RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.
fa-IR: RAID-6 می‌تواند به عنوان افزونه‌ای برای RAID-5 در نظر گرفته شود، به صورتی که هر سری از N بلاک شامل دو بلاک افزونگی داده است و هر یک از این N+2 بلاک میان N+2 دیسک تقسیم می‌شود.

en: This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.
fa-IR: این سطح RAID در مقایسه با دو سطح قبلی هزینه بیشتری در پی دارد، ولی امنیت بیشتری نیز به همراه می‌آورد چرا که تا دو درایو از N+2 دیسک موجود در صورت معیوب شدن می‌توانند بکار خود ادامه دهند. نقطه مقابل آن این است که عملیات نوشتن شامل یک بلاک داده و دو بلاک افزونگی دیگر است، که این آرایه را در مقایسه با سطوح دیگر کندتر نیز می‌کند.

en: RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.
fa-IR: RAID-1+0 می‌تواند از چندین نقص دیسک فرار کند: تا N دیسک از 2N آرایه تعریف شده بالا که برای هر کدام از زوج‌های RAID-1 فراهم شده است، می‌تواند معیوب شود.

en: <emphasis>GOING FURTHER</emphasis> RAID-10
fa-IR: <emphasis>مطالعه بیشتر</emphasis> RAID-10

en: RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.
fa-IR: RAID-10 بیشتر به عنوان مترادفی برای RAID-1+0 استفاده می‌شود، اما در لینوکس به عنوان یک استاندارد بکار گرفته می‌شود. این تنظیم شامل سیستمی است که هر بلاک آن درون دو دیسک متفاوت ذخیره می‌شود، حتی با تعداد دیسک‌های فرد، عملیات رونوشت‌گیری با استفاده از مدل قابل پیکربندی به صورت بهینه انجام می‌شود.

en: Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.
fa-IR: عملکرد کلی سیستم با توجه به سطح افزونگی و مدل پارتیشن‌بندی متفاوت خواهد بود، همچنین فضای ذخیره‌سازی منطقی نیز روی آن تاثیرگذار است.

en: Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.
fa-IR: به طور مشخص، سطح RAID با توجه به محدودیت‌ها و نیازمندی‌های سیستم موجود انتخاب می‌شود. نکته اینکه یک رایانه می‌تواند شامل چندین آرایه RAID منحصربفرد به همراه پیکربندی‌های متفاوت باشد.

en: Setting up RAID
fa-IR: برپایی RAID

en: Setting up RAID volumes requires the <emphasis role="pkg">mdadm</emphasis> package; it provides the <command>mdadm</command> command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.
fa-IR: برپایی آرایه‌های RAID نیازمند بسته <emphasis role="pkg">mdadm</emphasis> است؛ که شامل دستور <command>mdadm</command> برای ایجاد و ویرایش این آرایه‌ها می‌باشد همراه با ابزارهای جانبی و اسکریپت‌هایی که آن را با سایر قسمت‌های سیستم از جمله مانیتورینگ یکپارچه می‌سازد.

en: Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:
fa-IR: مثال ما شامل سروری با چندین دیسک است که برخی از آن‌ها استفاده شده و برخی دیگر که آزاد هستند به عنوان RAID بکار گرفته می‌شوند. در حالت اولیه دیسک‌ها و پارتیشن‌های زیر را در اختیار داریم:

en: the <filename>sdb</filename> disk, 4 GB, is entirely available;
fa-IR: دیسک ۴ گیگابایت <filename>sdb</filename> کاملا موجود است؛

en: the <filename>sdc</filename> disk, 4 GB, is also entirely available;
fa-IR: دیسک ۴ گیگابایت <filename>sdc</filename> کاملا موجود است؛

en: on the <filename>sdd</filename> disk, only partition <filename>sdd2</filename> (about 4 GB) is available;
fa-IR: در دیسک <filename>sdd</filename> تنها پارتیشن ۴ گیگابایت <filename>sdd2</filename> موجود است؛

en: finally, a <filename>sde</filename> disk, still 4 GB, entirely available.
fa-IR: در نهایت، دیسک ۴ گیگابایت <filename>sde</filename> که کاملا موجود است.

en: <emphasis>NOTE</emphasis> Identifying existing RAID volumes
fa-IR: <emphasis>یادداشت</emphasis> شناسایی آرایه‌های موجود RAID

en: The <filename>/proc/mdstat</filename> file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.
fa-IR: فایل <filename>/proc/mdstat</filename> فهرستی از آرایه‌های موجود و شرایط آن‌ها را نگهداری می‌کند. در زمان ایجاد یک آرایه جدید RAID، باید دقت کرد که نام آن با نام آرایه‌ای موجود برابر نباشد.

en: We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:
fa-IR: با استفاده از این دیسک‌ها می‌خواهیم دو فضای ذخیره‌سازی بوجود آوریم، یکی RAID-0 و دیگری RAID-1. بیایید با آرایه RAID-0 شروع کنیم:

en: Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:
fa-IR: ایجاد یک آرایه RAID-1 مشابه قبل است که تفاوت آن تنها پس از فرآیند ایجاد مشخص می‌گردد:

en: <emphasis>TIP</emphasis> RAID, disks and partitions
fa-IR: <emphasis>نکته</emphasis> RAID، دیسک‌ها و پارتیشن‌ها

en: A few remarks are in order. First, <command>mdadm</command> notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.
fa-IR: چند نکته باقی می‌ماند. اول، <command>mdadm</command> تشخیص می‌دهد که دستگاه‌های فیزیکی شامل اندازه‌های متفاوت هستند؛ از آنجا که این امر منجر به گم شدن فضا در دیسک بزرگتر می‌شود، تاییدیه آن مورد نیاز است.

en: More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the <filename>/dev/md1</filename> is usable, and a filesystem can be created on it, as well as some data copied on it.
fa-IR: مهمتر از آن به حالت دیسک mirror توجه کنید. حالت عادی در آرایه RAID که به صورت mirror باشد مشابهت کامل محتوا در هر دو دیسک است. با این حال، ضمانتی برای بوجود آمدن این حالت در زمان ایجاد آرایه وجود ندارد. زیرمجموعه RAID خود این ضمانت را ایجاد می‌کند و به محض اینکه دستگاه RAID ساخته شود عملیات همگام‌سازی صورت می‌گیرد. بعد از گذشت زمان (که وابسته به اندازه‌ دیسک‌ها است) آرایه RAID به حالت “فعال” یا “تمیز” تغییر می‌یابد. نکته اینکه در زمان این فاز بازسازی، mirror در یک حالت ناپایدار قرار می‌گیرد که افزونگی داده در آن تضمین نمی‌شود . دیسکی که در این بازه زمانی دچار مشکل گردد ممکن است به حذف داده بینجامد. با توجه به این موضوع، قبل از فاز همگام‌سازی معمولا داده‌های بزرگ و حساس روی آرایه RAID قرار نمی‌گیرند. حتی در حالت ناپایدار نیز، <filename>/dev/md1</filename> قابل استفاده است و یک فایل سیستم می‌تواند روی آن ایجاد گردد و داده‌های روی آن قرار گیرند.

en: <emphasis>TIP</emphasis> Starting a mirror in degraded mode
fa-IR: <emphasis>نکته</emphasis> آغاز یک mirror در حالت ناپایدار

en: Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing <filename>missing</filename> instead of a device file as one of the arguments to <command>mdadm</command>. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.
fa-IR: بعضی وقت‌ها در زمان آغاز mirror از RAID-1 دو دیسک بلافاصله قابل دسترس نخواهند بود، برای نمونه به این دلیل که یکی از دیسک‌ها برای ذخیره داده‌هایی استفاده شده است که دیگری می‌خواهد از آن mirror بگیرد. در چنین شرایطی، امکان ارجاع یک آرایه RAID-1 ناپایدار با استفاده از پارامتر <filename>missing</filename> بجای نام دستگاه در <command>mdadm</command> وجود دارد. زمانی که از داده در “mirror” رونوشت گرفته شود، دیسک قدیمی می‌تواند به آرایه اضافه گردد. سپس همگام‌سازی صورت می‌گیرد که امکان افزونگی داده با استفاده از دیسک قدیمی را فراهم می‌آورد.

en: <emphasis>TIP</emphasis> Setting up a mirror without synchronization
fa-IR: <emphasis>نکته</emphasis> برپایی یک mirror بدون همگام‌سازی

en: RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.
fa-IR: آرایه‌های RAID-1 اغلب به منظور ایجاد یک دیسک جدید و خالی استفاده می‌شوند. از این رو محتوای اولیه دیسک خیلی حائز اهمیت نیست، از این رو باید دانست داده‌ای که پس از ایجاد فایل سیستم در آرایه قرار می‌گیرد قابل دسترس خواهد بود.

en: One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?
fa-IR: شاید این سوال پیش بیاید که هدف از همگام‌سازی دو دیسک در زمان ایجاد آرایه چیست. چرا به یکسان بودن محتوایی که روی ناحیه‌های این آرایه قرار می‌گیرد اهمیت بدهیم وقتی می‌دانیم تنها پس از نوشتن روی آن است که می‌توان به آن‌ها دسترسی داشت؟

en: Fortunately, this synchronization phase can be avoided by passing the <literal>--assume-clean</literal> option to <command>mdadm</command>. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.
fa-IR: خوشبختانه، این فاز همگام‌سازی می‌تواند با استفاده از گزینه <literal>--assume-clean</literal> در <command>mdadm</command> در نظر گرفته نشود. اگرچه، این گزینه ممکن است منجر به سردرگمی در مواردی شود که داده اولیه خوانده خواهد شد (برای نمونه، وقتی یک فایل سیستم هم اکنون روی دیسک موجود باشد)، به همین دلیل است که به صورت پیشفرض فعال نیست.

en: Now let's see what happens when one of the elements of the RAID-1 array fails. <command>mdadm</command>, in particular its <literal>--fail</literal> option, allows simulating such a disk failure:
fa-IR: اکنون بیایید ببینیم در زمان بروز مشکل برای یکی از آرایه‌های RAID-1 چه اتفاقی می‌افتد. <command>mdadm</command> و به طور خاص گزینه <literal>--fail</literal> آن، امکان شبیه‌سازی این نقص دیسک را بوجود می‌آورد:

en: The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the <filename>sdd</filename> disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, <filename>sdf</filename>:
fa-IR: محتوای آرایه هنوز قابل دسترس است (و در صورت اتصال به فایل سیستم، وقفه‌ای در برنامه‌ها ایجاد نمی‌شود) اما امنیت داده دیگر تضمین نمی‌شود: در صورت بروز نقص برای دیسک <filename>sdd</filename> داده از بین می‌رود. به منظور پیشگیری از این خطر دیسک معیوب را با <filename>sdf</filename> جایگزین می‌کنیم:

en: Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the <filename>sde</filename> disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:
fa-IR: در اینجا نیز، کرنل به صورت خودکار فاز بازسازی آرایه را آغاز می‌کند که طی آن با وجود قابل دسترس بودن، آرایه در یک حالت ناپایدار قرار دارد. زمانی که بازسازی تمام شود، آرایه RAID به حالت عادی خود باز می‌گردد. به منظور سازگاری با حالت کلاسیک RAID که از دو دیسک برای mirror استفاده می‌کند، می‌توان دیسک <filename>sde</filename> را حذف کرد؛

en: From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.
fa-IR: از این لحظه، درایو می‌تواند در زمان خاموش شدن سرور یا در صورت پشتیبانی سخت‌افزاری از how-swap به صورت دستی جدا گردد. چنین پیکربندی شامل برخی کنترلرهای SCSI، اغلب دیسک‌های SATA و درایوهای خارجی که روی USB یا Firewire است.

en: Backing up the Configuration
fa-IR: پشتیبان‌گیری از پیکربندی

en: Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the <filename>/etc/mdadm/mdadm.conf</filename> file, an example of which is listed here:
fa-IR: از این رو، پشتیبان‌گیری از فایل پیکربندی اهمیت می‌یابد. شیوه استاندارد اینکار ویرایش فایل <filename>/etc/mdadm/mdadm.conf</filename> است که مثالی از آن را در ادامه مشاهده می‌کنید:

en: <command>mdadm</command> configuration file
fa-IR: فایل پیکربندی<command>mdadm</command>

en: One of the most useful details is the <literal>DEVICE</literal> option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, <literal>partitions containers</literal>, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.
fa-IR: یکی از جزئیات کاربری آن گزینه <literal>DEVICE</literal> است، که دستگاه‌های مورد نیاز برای جستجوی خودکار اجزای آرایه‌های RAID در سیستم را مشخص می‌کند. در مثال ما، ما گزینه پیشفرض <literal>partitions containers</literal> را با فهرستی از دستگاه‌ها جایگزین کردیم چرا که قصد استفاده از تمام دیسک و نه قسمت‌هایی از پارتیشن آن را برای برخی آرایه‌ها داشتیم.

en: The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching <filename>/dev/md*</filename> device name).
fa-IR: دو خط آخر در مثال ما به کرنل اجازه می‌دهند که با استفاده از شماره آرایه عملیات تشخیص و راه‌اندازی آن‌ها را انجام دهد. اطلاعات جانبی ذخیره شده روی دیسک برای جمع‌آوری آرایه‌ها کافی است، ولی نه برای تشخیص شماره آن‌ها (و نام دستگاه <filename>/dev/md*</filename> منطبق با آن).

en: Fortunately, these lines can be generated automatically:
fa-IR: خوشبختانه، این خطوط به صورت خودکار تولید می‌شوند:

en: The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.
fa-IR: محتوای این دو خط آخر وابسته به تعداد دیسک‌های استفاده شده در آرایه نیست. پس هنگام جایگزینی یک دیسک معیوب با جدید نیازی به تولید مجدد این خطوط نیست. از طرف دیگر، در زمان ایجاد یا حذف یک آرایه RAID، این فایل باید بروزرسانی گردد.

en: LVM, the <emphasis>Logical Volume Manager</emphasis>, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.
fa-IR: LVM که مخفف <emphasis>Logical Volume Manager</emphasis> است، روشی دیگر برای انتزاع دستگاه‌های منطقی از نمونه‌های فیزیکی است که بجای قابلیت اعتماد روی افزایش انعطاف‌پذیری تمرکز دارد. LVM امکان تغییر یک دستگاه منطقی را به شیوه‌ای شفاف برای برنامه‌های کاربردی آن بوجود می‌آورد؛ برای نمونه، امکان افزودن دیسک‌های جدید، مهاجرت داده به آن‌ها و حذف دیسک‌های قدیمی بدون قطع اتصال دستگاه مجازی وجود دارد.

en: LVM Concepts
fa-IR: مفاهیم LVM

en: This flexibility is attained by a level of abstraction involving three concepts.
fa-IR: این انعطاف‌پذیری از طریق یک سطح انتزاعی همراه با سه مفهوم بدست می‌آید.

en: First, the PV (<emphasis>Physical Volume</emphasis>) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.
fa-IR: اول، PV یا <emphasis>Physical Volume</emphasis> نزدیک‌ترین موجودیت به سخت‌افزار است: می‌تواند پارتیشن‌های روی یک دیسک، یک دیسک کامل یا حتی سایر دستگاه‌های بلاک-محور (از جمله یک آرایه RAID) باشد. به یاد داشته باشید زمانی که یک عنصر فیزیکی به عنوان PV برای LVM تنظیم می‌شود، تنها باید توسط LVM قابل دسترس باشد در غیر اینصورت سیستم دچار سردرگمی می‌گردد.

en: The third kind of object is the LV (<emphasis>Logical Volume</emphasis>), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in <filename>/dev</filename>, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).
fa-IR: سومین مفهوم نیز LV یا <emphasis>Logical Volume</emphasis> نام دارد، که تکه‌ای از یک VG به حساب می‌آید؛ اگر VG را با یک دیسک مقایسه کنیم، LV مانند یک پارتیشن خواهد بود. LV به عنوان یک دستگاه بلاک-محور همراه با مدخلی در <filename>/dev</filename> ظاهر می‌شود، که می‌تواند به عنوان هر پارتیشن فیزیکی دیگر مورد استفاده قرار گیرد (بیشتر در مورد یک فایل سیستم میزبان یا فضای swap).

en: The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.
fa-IR: نکته مهم در تقسیم یک VG به LV این است که کاملا مستقل از اجزای فیزیکی آن (PV) انجام می‌شود. یک VG تنها با یک قسمت فیزیکی (مانند یک دیسک) می‌تواند به چندین دستگاه منطقی تقسیم شود؛ به طور مشابه، یک VG با چندین دیسک فیزیکی می‌تواند به عنوان یک دستگاه منطقی بزرگ ظاهر شود. تنها محدودیت مشخص این است که اندازه کل اختصاص یافته به LVها نمی‌تواند بیشتر از مجموع اندازه PVها در گروه دستگاه‌ها باشد.

en: It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.
fa-IR: اغلب منطقی است که به منظور داشتن همگنی بین اجزای فیزیکی یک VG، آن را به دستگاه‌های مجازی تقسیم کرد که الگوهای مشابهی در کارکرد داشته باشند. برای نمونه، اگر سخت‌افزار موجود شامل دیسک‌های سریع و کند باشد، دیسک‌های سریع می‌توانند درون یک VG و دیسک‌های کند درون دیگری قرار گیرند؛ تکه‌های اولی می‌توانند به برنامه‌هایی اختصاص یابند که نیازمند دسترسی سریع به دیسک هستند، در صورتی که از دومی برای سایر وظایف متداول دیسک استفاده می‌شود.

en: In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).
fa-IR: در هر صورت، به خاطر بسپارید که یک LV به طور مشخص به هیچ PV متصل نیست. امکان تاثیرگذاری روی جایی که داده از یک LV به صورت فیزیکی می‌آید وجود دارد، اما این امکان برای کاربردهای روزانه الزامی نیست. از طرف دیگر، زمانی که مجموعه فیزیکی از اجزای یک VG گسترش می‌یابند، مکان ذخیره‌سازی فیزیکی منطبق با یک LV می‌توانند بین چند دیسک مهاجرت کنند (به صورتی که درون PVهای اختصاص‌یافته به VG قرار داشته باشند).

en: Setting up LVM
fa-IR: برپایی LVM

en: Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:
fa-IR: بیایید فرآیند گام به گام برپایی LVM برای یک کاربرد متداول را دنبال کنیم: می‌خواهیم یک موقعیت ذخیره‌سازی پیچیده را ساده کنیم. چنین موقعیتی معمولا با گذشت زمان و گره خوردن مقیاس‌های موقتی انباشتگی صورت می‌گیرد. برای این منظور، سروری را در نظر می‌گیریم که نیازهای ذخیره‌سازی آن طی زمان تغییر کرده است که پارتیشن‌های موجود آن بین چندین دیسک فیزیکی مختلف به مانند یک مسیر مارپیچ قرار گرفته‌اند. به عبارت دیگر، پارتیشن‌های زیر موجود هستند:

en: on the <filename>sdb</filename> disk, a <filename>sdb2</filename> partition, 4 GB;
fa-IR: درون دیسک <filename>sdb</filename>،‌ یک پارتیشن ۴ گیگابایت به نام <filename>sdb2</filename>؛

en: on the <filename>sdc</filename> disk, a <filename>sdc3</filename> partition, 3 GB;
fa-IR: درون دیسک <filename>sdc</filename>،‌ یک پارتیشن ۳ گیگابایت به نام <filename>sdc3</filename>؛

en: the <filename>sdd</filename> disk, 4 GB, is fully available;
fa-IR: دیسک <filename>sdd</filename>،‌ با ظرفیت ۴ گیگابایت کاملا موجود؛

en: on the <filename>sdf</filename> disk, a <filename>sdf1</filename> partition, 4 GB; and a <filename>sdf2</filename> partition, 5 GB.
fa-IR: درون دیسک <filename>sdf</filename>،‌ یک پارتیشن ۴ گیگابایت به نام <filename>sdf1</filename> و یک پارتیشن ۵ گیگابایت به نام <filename>sdf2</filename>.

en: In addition, let's assume that disks <filename>sdb</filename> and <filename>sdf</filename> are faster than the other two.
fa-IR: علاوه بر این، تصور می‌کنیم که دیسک‌های <filename>sdb</filename> و <filename>sdf</filename> سریع‌تر از دو دیسک دیگر هستند.

en: Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.
fa-IR: هدف ما برپایی یه دستگاه منطقی برای سه برنامه مختلف است: یک سرور فایل که به ۵ گیگابایت فضای ذخیره‌سازی نیاز دارد، یک پایگاه‌داده (۱ گیگابایت) و فضایی برای پشتیبان‌گیری (۱۲ گیگابایت). دوتای اول به عملکرد بالا نیاز دارند اما پشتیبان‌گیری چنین حساسیتی در دسترسی سریع ندارد. تمام این محدودیت‌ها از استفاده پارتیشن‌ها به صورت مستقیم جلوگیری می‌کنند؛ استفاده از LVM می‌تواند اندازه فیزیکی از دستگاه‌ها را انتزاعی کند، که تنها محدودیت آن مجموع فضای ذخیره‌سازی است.

en: The required tools are in the <emphasis role="pkg">lvm2</emphasis> package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.
fa-IR: ابزارهای مورد نیاز در بسته <emphasis role="pkg">lvm2</emphasis> و وابستگی‌های آن قرار دارند. زمانی که نصب شوند، برپایی LVM شامل سه گام می‌شود که با سه سطح از مفاهیم آن مرتبط است.

en: First, we prepare the physical volumes using <command>pvcreate</command>:
fa-IR: ابتدا دستگاه‌های فیزیکی را با استفاده از <command>pvcreate</command> آماده‌سازی می‌کنیم:

en: So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the <command>pvdisplay</command> command lists the existing PVs, with two possible output formats.
fa-IR: تا اینجا مشکلی نیست؛ به یاد داشته باشید که یک PV می‌تواند روی یک دیسک کامل یا پارتیشن‌های انفرادی ایجاد گردد. دستور <command>pvdisplay</command> فهرستی از PVها را با دو قالب خروجی ممکن نمایش می‌دهد.

en: Now let's assemble these physical elements into VGs using <command>vgcreate</command>. We'll gather only PVs from the fast disks into a <filename>vg_critical</filename> VG; the other VG, <filename>vg_normal</filename>, will also include slower elements.
fa-IR: اکنون بیایید این عناصر فیزیکی را با استفاده از <command>vgcreate</command> درون VG قرار دهیم. PV دیسک‌های سریع را درون VG به نام <filename>vg_critical</filename> و دیسک‌های کند را درون VG به نام <filename>vg_normal</filename> قرار می‌دهیم.

en: Here again, commands are rather straightforward (and <command>vgdisplay</command> proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a <filename>vg_</filename> prefix to name our VGs, but it is nothing more than a convention.
fa-IR: در اینجا نیز دستورات واضح هستند و <command>vgdisplay</command> شامل دو قالب خروجی است. به یاد داشته باشید که امکان استفاده از دو پارتیشن یک دیسک فیزیکی درون دو VG مختلف وجود دارد. ما از یک پیشوند <filename>vg_</filename> برای نامگذاری VGها استفاده کردیم، اما چیزی بیشتر از رعایت یک استاندارد نیست.

en: Two parameters are required when creating logical volumes; they must be passed to the <command>lvcreate</command> as options. The name of the LV to be created is specified with the <literal>-n</literal> option, and its size is generally given using the <literal>-L</literal> option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.
fa-IR: برای ایجاد دستگاه‌های منطقی دو پارامتر مورد نیاز است؛ که باید به صورت گزینه‌ها به <command>lvcreate</command> ارسال گردند. نام LV که قصد ایجاد آن را داریم با گزینه <literal>-n</literal> و اندازه آن با گزینه <literal>-L</literal> مشخص می‌شود. البته، به دستور باید اعلام کنیم که از کدام VG می‌خواهیم استفاده شود.

en: <emphasis>GOING FURTHER</emphasis> <command>lvcreate</command> options
fa-IR: <emphasis>مطالعه بیشتر</emphasis> گزینه‌های <command>lvcreate</command>

en: The <command>lvcreate</command> command has several options to allow tweaking how the LV is created.
fa-IR: دستور <command>lvcreate</command> شامل چندین گزینه است که چگونگی ایجاد LV را مشخص می‌کند.

en: Let's first describe the <literal>-l</literal> option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, <emphasis>physical extents</emphasis>, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the <literal>-l</literal> option will probably be preferred over <literal>-L</literal>.
fa-IR: ابتدا بیایید گزینه <literal>-l</literal> را توضیح دهیم، که با استفاده از آن اندازه LV می‌تواند به عنوان تعداد بلاک‌ها در مقایسه با واحدهای “انسانی” که در بالا استفاده کردیم مشخص گردد. این بلاک‌ها که به نام PE یا <emphasis>physical extents</emphasis> در زبان LVM مطرح می‌شوند، واحدهای پیوسته از فضای ذخیره‌سازی در PVها می‌باشند که نمی‌توان آن‌ها را بین LVها تقسیم کرد. زمانی که می‌خواهیم یک فضای ذخیره‌سازی با دقت بالا را برای یک LV تعریف کنیم، برای نمونه استفاده از فضای کامل، استفاده از گزینه <literal>-l</literal> بر <literal>-L</literal> اولویت پیدا می‌کند.

en: Logical volumes, once created, end up as block device files in <filename>/dev/mapper/</filename>:
fa-IR: گروه‌های مجازی، زمانی که ایجاد گردند، به عنوان فایل‌های دستگاه درون <filename>/dev/mapper/</filename> قرار می‌گیرند:

en: When the computer boots, the <filename>lvm2-activation</filename> systemd service unit executes <command>vgchange -aay</command> to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.
fa-IR: زمانی که رایانه راه‌اندازی می‌شود واحد سرویس systemd به نام <filename>lvm2-activation</filename> به اجرای <command>vgchange -aay</command> می‌پردازد که اینکار گروه‌های مجازی را “فعال” می‌کند: ابتدا به پویش دستگاه‌های موجود می‌پردازد؛ آن‌هایی که توسط گروه‌های فیزیکی برای LVM آماده‌سازی شده‌اند درون زیرسیستم آن قرار می‌گیرند، آن‌هایی که متعلق به گروه‌های مجازی باشند گردآوری شده و گروه‌های مجازی آن أغاز و قابل استفاده می‌گردند. بنابراین هنگام ایجاد یا تغییر گروه‌های LVM نیازی به ویرایش فایل‌های پیکربندی نیست.

en: Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in <filename>/etc/lvm/backup</filename>, which can be useful in case of a problem (or just to sneak a peek under the hood).
fa-IR: با این حال، به یاد داشته باشید که ساختار عناصر LVM (گروه‌های فیزیکی و منطقی همراه با گروه‌های دستگاه) در <filename>/etc/lvm/backup</filename> پشتیبان‌گیری می‌شوند، که می‌تواند در زمان بروز مشکل (یا اطلاع از عملکرد آن) مورد استفاده قرار گیرد.

en: To make things easier, convenience symbolic links are also created in directories matching the VGs:
fa-IR: برای ساده‌تر کردن کارها، پیوندهای نمادین متعارف نیز در دایرکتوری‌های شامل VGها ایجاد شده است:

en: The LVs can then be used exactly like standard partitions:
fa-IR: سپس LVها می‌توانند مانند پارتیشن‌های استاندارد مورد استفاده قرار گیرند:

en: From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.
fa-IR: از دید برنامه‌های کاربردی، تعداد بیشمار پارتیشن‌ها اکنون به یک دستگاه بزرگ ۱۲ گیگابایت تبدیل شده است که نام راحت‌تری نیز دارد.

en: LVM Over Time
fa-IR: LVM در گذر زمان

en: Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in <filename>vg_critical</filename>, we can grow <filename>lv_files</filename>. For that purpose, we'll use the <command>lvresize</command> command, then <command>resize2fs</command> to adapt the filesystem accordingly:
fa-IR: با اینکه توانایی گردآوری پارتیشن‌‌ها یا دیسک‌های فیزیکی بسیار متداول است، این تنها مزیت استفاده از LVM نیست. انعطاف‌پذیری آن در گذر زمان و تغییر رویکرد ذخیره‌سازی، مشخص می‌شود. در مثال ما، تصور کنیم که فایل‌های بزرگ جدیدی قرار است درون سرور فایل قرار گیرند که LV اختصاص‌یافته به آن گنجایش کافی را ندارد. از آنجا که از تمام فضای <filename>vg_critical</filename> استفاده نکرده‌ایم، می‌توانیم <filename>lv_files</filename> را گسترش دهیم. برای این منظور، با استفاده از دستور <command>lvresize</command> و <command>resize2fs</command> برای سازگاری فایل سیستم اینکار صورت می‌گیرد:

en: <emphasis>CAUTION</emphasis> Resizing filesystems
fa-IR: <emphasis>احتیاط</emphasis> تغییر اندازه فایل سیستم‌ها

en: The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.
fa-IR: فایل سیستم‌های ext3، ext4 و zfs بدون نیاز به قطع اتصال می‌توانند افزایش یابند؛ کاهش اندازه نیازمند قطع اتصال است. فایل سیستم reiserfs امکان تغییر اندازه آنلاین را در دو جهت فراهم می‌سازد. ext2 مقدس، اما نیازمند قطع اتصال در دو جهت است.

en: We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:
fa-IR: برای توسعه گروهی که از پایگاه‌داده میزبانی می‌کند نیز به همین ترتیب می‌توان اقدام کرد، با این تفاوت که به انتهای فضای ذخیره‌سازی موجود VG رسیدیم:

en: <emphasis>GOING FURTHER</emphasis> Advanced LVM
fa-IR: <emphasis>مطالعه بیشتر</emphasis> LVM پیشرفته

en: RAID or LVM?
fa-IR: RAID یا LVM؟

en: RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.
fa-IR: RAID و LVM بدون تردید دارای مزایایی هستند که در صورت کنار گذاشتن فرضیه یک رایانه رومیزی همراه با یک هارد دیسک که کارکرد آن در طول زمان تغییر نمی‌کند، مشخص می‌شوند. اگرچه، RAID و LVM در دو جهت مختلف حرکت می‌کنند و اهداف متفاوتی نیز دارند، که گاهی تصمیم‌گیری درباره استفاده صحیح از آن‌ها را دشوار می‌سازد. مناسب‌ترین پاسخ بستگی به نیازمندی‌های فعلی و قابل پیشبینی سیستم در آینده دارد.

en: There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.
fa-IR: موارد ساده‌ای وجود دارد که پرسشی درباره آن‌ها مطرح نمی‌شود. اگر نیازمندی این باشد که داده برابر نقص سخت‌افزاری محافظت گردد، به طور مشخص باید از RAID به صورت آرایه‌ای از دیسک‌ها استفاده کرد، چرا که LVM درباره این مشکل راهکاری ندارد. از طرف دیگر، اگر نیازمندی این باشد که یک طرح ذخیره‌سازی انعطاف‌پذیر از گروه‌های مستقل ساختار فیزیکی دیسک‌ها تشکیل گردد، به طور مشخص باید از LVM استفاده کرد چرا که RAID درباره این مشکل راهکاری ندارد.

en: <emphasis>NOTE</emphasis> If performance matters…
fa-IR: <emphasis>یادداشت</emphasis> اگر عملکرد مهم باشد...

en: The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.
fa-IR: سومین کارکرد قابل ذکر زمانی است که بخواهیم دو دیسک را در یک گروه بزرگ‌تر قرار دهیم، خواه به دلایل عملکرد یا داشتن یک فایل سیستم بزرگ‌تر از فضای هر کدام از دیسک‌ها). اینکار با استفاده از یک RAID-0 (یا حتی RAID خطی) و گروه LVM انجام می‌شود. در این موقعیت، بجز محدودیت‌های خارجی (برای نمونه، در چارچوب سایر رایانه‌ها بودن اگر آن‌ها نیز تنها از RAID استفاده کنند)، پیکربندی مورد نظر معمولا LVM خواهد بود. راه‌اندازی اولیه به ندرت پیچیده‌تر خواهد بود و این افزایش پیچیدگی در صورت تغییر نیازمندی‌ها یا افزودن دیسک‌ها جدید قابلیت انعطاف‌پذیری بیشتری را فراهم می‌آورد.

en: Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.
fa-IR: البته یک مورد بسیار جالب نیز وجود دارد، که سیستم ذخیره‌سازی هم باید برابر نقص سخت‌افزاری مقاوم هم انعطاف‌پذیری لازم درباره اختصاص گروه‌های مختلف را داشته باشد. هیچ یک از راهکارهای RAID یا LVM به تنهایی نمی‌توانند این نیازمندی را پوشش دهند؛ اینجا است که از هر دو به صورت همزمان استفاده می‌کنیم - یا یکی بر فراز دیگری. طرح کلی در این مورد و با توجه به اینکه این دو فناوری به بلوغ رسیده‌اند این است که ابتدا با گروه‌بندی دیسک‌ها در تعداد آرایه‌های کوچک RAID از افزونگی داده اطمینان حاصل کرد سپس از این آرایه‌ها برای گروه‌های فیزیکی LVM استفاده کنیم؛ پارتیشن‌های منطقی از این LVها برای فایل سیستم بوجود می‌آیند. نتیجه این تنظیم این است که هنگامی که یک دیسک دچار نقص می‌گردد، تنها تعداد کمی از آرایه‌های RAID نیازمند بازسازی هستند، که اینکار زمان سپری شده توسط مدیر سیستم برای بازیابی را کاهش می‌دهد.

en: RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as <filename>sda</filename> and <filename>sdc</filename>. They are partitioned identically along the following scheme:
fa-IR: از RAID-1 و LVM به صورت ترکیبی برای رفع این محدودیت‌ها استفاده شده است. دیسک‌ها به دو کنترلر مختلف SATA به منظور بهینه‌سازی دسترسی موازی و کاهش خطر نقص همزمان متصل شده‌اند که به عنوان <filename>sda</filename> و <filename>sdc</filename> ظاهر می‌شوند. آن‌ها با توجه به طرح زیر پارتیشن‌بندی شده‌اند:

en: Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in <filename>vg_raid</filename> will be preserved even if one of the disks fails, which will not be the case for LVs created in <filename>vg_bulk</filename>; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.
fa-IR: زمانی که VGها ایجاد شوند، به روشی بسیار منعطف می‌توانند پارتیشن‌بندی گردند. به یاد داشته باشید که LVهای ایجاد شده در <filename>vg_raid</filename> در صورت نقص دیسک‌ها نیز نگهداری می‌شوند که این مورد درباره LVهای ایجاد شده در <filename>vg_bulk</filename> صادق نیست؛ از طرف دیگر، مورد دوم به صورت موازی در اختیار هر دو دیسک قرار می‌گیرد، که امکان خواندن یا نوشتن فایل‌های بزرگ را فراهم می‌آورد.

en: <emphasis>NOTE</emphasis> Why three RAID-1 volumes?
fa-IR: <emphasis>یادداشت</emphasis> چرا از سه آرایه RAID-1 استفاده شد؟

en: We could have set up one RAID-1 volume only, to serve as a physical volume for <filename>vg_raid</filename>. Why create three of them, then?
fa-IR: می‌توانستیم از یک آرایه RAID-1 به منظور گروه فیزیکی برای <filename>vg_raid</filename> استفاده می‌کردیم. پس چرا سه تا ایجاد کردیم؟

en: The rationale for the first split (<filename>md0</filename> vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.
fa-IR: منطق تقسیم اول (<filename>md0</filename> مقابل دیگران) درباره امنیت داده است: داده‌ای که روی هر دو عنصر یک mirror از RAID-1 نوشته می‌شود کاملا یکسان است و این امکان وجود دارد که با نادیده‌گرفتن ساختار RAID یکی از دیسک‌ها را به صورت مستقیم متصل کنیم. در صورتی که یک باگ کرنل موجود باشد، برای نمونه اگر اطلاعات جانبی LVM خراب شود، امکان راه‌اندازی حداقلی سیستم برای دسترسی به داده حیاتی مانند ساختار دیسک‌های موجود در آرایه‌های RAID و LVM موجود است؛ این اطلاعات جانبی می‌تواند بازسازی شده و فایل‌ها دوباره قابل دسترس شوند، تا سیستم به حالت عادی خود بازگردد.

en: <primary>virtualization</primary>
fa-IR: <primary>مجازی‌سازی</primary>

en: Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.
fa-IR: مجازی‌سازی یکی از بزرگترین پیشرفت‌های علوم رایانه در سال‌های اخیر است. این عبارت شامل چندین مفهوم انتزاعی و تکنیکی است که در شبیه‌سازی رایانه‌های مجازی به طوری که مستقل از سخت‌افزار واقعی عمل می‌کنند. یک سرور فیزیکی می‌تواند شامل چندین سرور مجازی باشد که جدا از یکدیگر فعالیت می‌کنند. برنامه‌های کاربردی آن بسیار هستند که از این انزوا مشتق می‌شوند: برای نمونه، محیط‌های آزمایشی همراه با پیکربندی‌های متفاوت یا جداسازی سرویس‌های میزبانی بین چندین ماشین مجازی برای امنیت.

en: There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:
fa-IR: راهکارهای گوناگون مجازی‌سازی هر کدام با نقاط قوت و ضعف خود وجود دارند. تمرکز این کتاب روی Xen، LXC و KVM است اما سایر پیاده‌سازی‌های قابل ذکر عبارتند از:

en: Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).
fa-IR: ... نیز یک ماشین مجازی آزاد دیگر است، اما تنها به شبیه‌سازی معماری‌های x86 می‌پردازد (i386 و amd64).

en: Xen <indexterm><primary>Xen</primary></indexterm> is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.
fa-IR: Xen <indexterm><primary>Xen</primary></indexterm> یک راهکار “paravirtualization” است که شامل یک لایه انتزاعی سبک به نام “hypervisor” می‌باشد که بین سخت‌افزار و سیستم‌های بالایی قرار می‌گیرد؛ این لایه مانند یک داور دسترسی از ماشین‌های مجازی به سخت‌افزار را کنترل می‌کند. اگرچه، تنها شامل چند دستورالعمل کوتاه است، باقی عملیات به طور مستقیم از طرف سخت‌افزار و به نیابت از سیستم‌های دیگر انجام می‌شوند. مزیت اصلی آن این است که عملکرد کاهش نمی‌یابد و سیستم‌های تقریبا با سرعت اصلی سخت‌افزار اجرا می‌شوند؛ اشکال اصلی آن این است که کرنل‌های سیستم عامل‌ها به منظور استفاده از hypervisor باید سازگار با Xen باشند.

en: <emphasis>CULTURE</emphasis> Xen and the various versions of Linux
fa-IR: <emphasis>فرهنگ</emphasis> Xen و نسخه‌های مختلف از لینوکس

en: Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the <emphasis>paravirt_ops</emphasis> or <emphasis>pv_ops</emphasis> interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.
fa-IR: Xen در ابتدا به عنوان چندین اصلاحیه خارج از ساختار اصلی کرنل لینوکس توسعه یافت. در همان زمان، چندین راهکاری مجازی‌سازی دیگر (از جمله KVM) نیازمند چندین عملکرد عمومی مجازی‌سازی بودند تا یکپارچه‌سازی خود را تسهیل نمایند و کرنل لینوکس این مجموعه قابلیت‌ها را گردآوری کرد (که به عنوان رابط <emphasis>paravirt_ops</emphasis> یا <emphasis>pv_ops</emphasis> شناخته می‌شوند). از آنجا که اصلاحیه‌های Xen این قابلیت‌ها را به شیوه‌ای دیگر پیاده‌سازی می‌کردند، نتوانستند به صورت رسمی پذیرفته شوند.

en: <emphasis>CULTURE</emphasis> Xen and non-Linux kernels
fa-IR: <emphasis>فرهنگ</emphasis> Xen کرنل‌های غیر از لینوکس

en: However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).
fa-IR: با این حال، اگر Xen بتواند روی قابلیت‌های سخت‌افزاری موجود برای مجازی‌سازی تکیه کند (که تنها در پردازنده‌های جدید مشاهده می‌شوند)، حتی سیستم عامل‌های غیر-قابل تغییر مانند ویندوز نیز می‌توانند به عنوان domU استفاده گردند.

en: <emphasis>NOTE</emphasis> Architectures compatible with Xen
fa-IR: <emphasis>یادداشت</emphasis> معماری‌های سازگار با Xen

en: Xen is currently only available for the i386, amd64, arm64 and armhf architectures.
fa-IR: Xen هم اکنون تنها برای معماری‌های i386، amd64، arm64 و armhf موجود می‌باشد.

en: Using Xen under Debian requires three components:
fa-IR: استفاده از Xen تحت دبیان نیازمند سه مولفه است:

en: The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the <emphasis role="pkg">libc6-xen</emphasis> package.
fa-IR: معماری i386 همچنین نیازمند یک کتابخانه استاندارد است که بتواند از اصلاحیه‌های موجود در Xen بهره‌مند شود؛ این کتابخانه در بسته <emphasis role="pkg">libc6-xen</emphasis> موجود است.

en: Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.
fa-IR: زمانی که این پیشنیازها نصب شوند، گام بعدی آزمایش عملکرد خود dom0 است؛ این عمل شامل راه‌اندازی مجدد hypervisor و کرنل Xen می‌باشد. سیستم باید به شیوه استاندارد خود راه‌اندازی شده، همراه با چندین پیام که طی گام‌های اولیه راه‌اندزای در کنسول نمایش می‌یابند.

en: Now is the time to actually install useful systems on the domU systems, using the tools from <emphasis role="pkg">xen-tools</emphasis>. This package provides the <command>xen-create-image</command> command, which largely automates the task. The only mandatory parameter is <literal>--hostname</literal>, giving a name to the domU; other options are important, but they can be stored in the <filename>/etc/xen-tools/xen-tools.conf</filename> configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the <command>xen-create-image</command> invocation. Important parameters of note include the following:
fa-IR: اکنون زمان آن فرا رسیده است که با استفاده از ابزار موجود در <emphasis role="pkg">xen-tools</emphasis> به نصب سیستم‌های کاربردی روی domU بپردازیم. این بسته شامل دستور <command>xen-create-image</command> می‌باشد که تقریبا این فرآیند را خودکارسازی می‌کند. تنها پارامتر ضروری آن <literal>--hostname</literal> است که نام domU را مشخص می‌کند؛ سایر گزینه‌ها نیز مهم هستند ولی می‌توانند درون فایل پیکربندی <filename>/etc/xen-tools/xen-tools.conf</filename> قرار بگیرند که نبود آن‌ها خطایی را در هنگام اجرای دستور صادر نمی‌کند. بنابراین مهم است که محتوای این فایل را قبل از ایجاد هر image بررسی کرده یا از پارامترهای اضافی هنگام فراخوانی <command>xen-create-image</command> استفاده کنیم. پارامترهای مهم قابل ذکر عبارتند از:

en: <literal>--memory</literal>, to specify the amount of RAM dedicated to the newly created system;
fa-IR: <literal>--memory</literal>، برای مشخص کردن میزان RAM اختصاص یافته به سیستم جدید؛

en: <literal>--size</literal> and <literal>--swap</literal>, to define the size of the “virtual disks” available to the domU;
fa-IR: <literal>--size</literal> و <literal>--swap</literal>، برای تعریف اندازه "دیسک‌های مجازی" موجود برای domU؛

en: <emphasis>GOING FURTHER</emphasis> Installing a non-Debian system in a domU
fa-IR: <emphasis>مطالعه بیشتر</emphasis> نصب یک سیستم غیر دبیان در یک domU

en: In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the <literal>--kernel</literal> option.
fa-IR: در مورد یک سیستم غیر-لینوکس، برای تعریف کرنل مورد استفاده domU باید دقت کرد، با استفاده از گزینه <literal>--kernel</literal>.

en: <literal>--dhcp</literal> states that the domU's network configuration should be obtained by DHCP while <literal>--ip</literal> allows defining a static IP address.
fa-IR: <literal>--dhcp</literal> بیان می‌کند که پیکربندی شبکه domU باید از طریق DHCP انجام شود در صورتی که <literal>--ip</literal> امکان استفاده از نشانی ایستای IP را فراهم می‌کند.

en: Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the <literal>--dir</literal> option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the <literal>--lvm</literal> option, followed by the name of a volume group; <command>xen-create-image</command> will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.
fa-IR: در انتها، از یک روش ذخیره‌سازی به منظور ایجاد image استفاده کرد (آن‌هایی که به عنوان درایوهای هارد دیسک از domU در نظر گرفته می‌شوند). ساده‌ترین روش، با توجه به گزینه <literal>--dir</literal>، ایجاد یک فایل در dom0 به ازای هر دستگاه domU فراهم‌کننده آن است. برای سیستم‌هایی که از LVM استفاده می‌کنند، گزینه جایگزین استفاده از <literal>--lvm</literal> است، که همراه با نام یک گروه آرایه آورده می‌شود؛ سپس <command>xen-create-image</command> اقدام به ایجاد یک گروه منطقی درون آرایه‌ها می‌کند که این گروه منطقی به عنوان یک درایو هارد دیسک به domU معرفی می‌گردد.

en: <emphasis>NOTE</emphasis> Storage in the domU
fa-IR: <emphasis>یادداشت</emphasis> ذخیره‌سازی در domU

en: Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by <command>xen-create-image</command>, however, so editing the Xen image's configuration file is in order after its initial creation with <command>xen-create-image</command>.
fa-IR: علاوه بر پارتیشن‌ها، آرایه‌های RAID و گروه‌های منطقی موجود در LVM، هارد دیسک‌های کامل نیز می‌توانند به domU انتقال یابند. این عملیات توسط <command>xen-create-image</command> به صورت خودکار انجام نمی‌شوند، با این حال، ویرایش فایل پیکربندی Xen معمولا پس از فراخوانی اولیه <command>xen-create-image</command> صورت می‌گیرد.

en: Once these choices are made, we can create the image for our future Xen domU:
fa-IR: زمانی که این انتخاب‌ّها صورت گیرد، می‌توانیم image خود را برای domU بعدی در Xen ایجاد کنیم:

en: We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.
fa-IR: اکنون دارای یک ماشین مجازی هستیم که اجرا نمی‌شود (و تنها از فضای موجود در هارد دیسک dom0 استفاده می‌کند). البته که می‌توانیم با استفاده از پارامترهای گوناگون دیگر image بیشتری بسازیم.

en: The simplest model is the <emphasis>bridge</emphasis> model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.
fa-IR: ساده‌ترین مدل <emphasis>bridge</emphasis> است؛ تمام کارت‌های شبکه eth0 (در سیستم‌های dom0 و domU) طوری عمل می‌کنند گویی به سوئیچ اصلی Ethernet متصل شده‌اند.

en: Then comes the <emphasis>routing</emphasis> model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.
fa-IR: سپس مدل <emphasis>routing</emphasis> قرار دارد، به صورتی که dom0 به عنوان یک مسیریاب میان سیستم‌های domU و شبکه خارجی (فیزیکی) قرار می‌گیرد.

en: Finally, in the <emphasis>NAT</emphasis> model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.
fa-IR: در نهایت، در مدل <emphasis>NAT</emphasis>، dom0 بین سیستم‌های domU و باقی شبکه قرار می‌گیرد، اما سیستم‌های domU به صورت مستقیم از خارج قابل دسترس نیستند و ترافیک از طریق ترجمه نشانی شبکه یا NAT با استفاده از dom0 انتقال می‌یابد.

en: These three networking nodes involve a number of interfaces with unusual names, such as <filename>vif*</filename>, <filename>veth*</filename>, <filename>peth*</filename> and <filename>xenbr0</filename>. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.
fa-IR: این سه مدل شبکه دارای تعدادی رابط با نام‌های نامتعارف هستند از جمله <filename>vif*</filename>، <filename>veth*</filename>، <filename>peth*</filename> و <filename>xenbr0</filename>. hypervisor موجود در Xen با توجه به لایه تعریف شده آن‌ها را مرتب‌سازی می‌کند که این کار با استفاده از ابزارهای سمت-کاربر صورت می‌گیرد. از آنجا که مدل‌های NAT و routing تنها برای موارد خاص کاربرد دارند، تنها به بررسی مدل bridge می‌پردازیم.

en: <emphasis>TOOL</emphasis> Choice of toolstacks to manage Xen VM
fa-IR: <emphasis>ابزار</emphasis> انتخاب جعبه ابزار برای مدیریت ماشین مجازی Xen

en: <emphasis>CAUTION</emphasis> Only one domU per image!
fa-IR: <emphasis>احتیاط</emphasis> تنها یک domU برای هر image!

en: Note that the <filename>testxen</filename> domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.
fa-IR: به یاد داشته باشید که domU ایجاد شده بنام ... از حافظه واقعی گرفته شده از RAM که معمولا برای dom0 در نظر گرفته می‌شود، استفاده می‌کند و نه یک حافظه شبیه‌سازی شده. بنابراین هنگام راه‌اندازی یک سرور مبتی بر Xen باید دقت عمل در تخصیص حافظه به خرج داد.

en: Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the <filename>hvc0</filename> console, with the <command>xl console</command> command:
fa-IR: بسیار خوب! ماشین مجازی ما راه‌اندازی شد. دو روش دسترسی به آن وجود دارد. روش معمول اتصال ... به آن است، مانند یک ماشین حقیقی که از طریق شبکه متصل می‌شویم؛ اینکار نیازمند برپایی یک سرور DHCP یا پیکربندی DNS جداگانه است. روش دیگر، که در صورت اشتباه بودن پیکربندی شبکه می‌تواند تنها روش ممکن باشد، استفاده از کنسول <filename>hvc0</filename> همراه با دستور <command>xl console</command> است:

en: One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> key combination.
fa-IR: در این حالت می‌توان یک نشست جداگانه برای دسترسی به ماشین مجازی ایجاد کرد. قطع اتصال این کنسول با استفاده از کلید ترکیبی <keycombo action="simul"><keycap>Control</keycap> <keycap>]</keycap></keycombo> انجام می‌شود.

en: <emphasis>TIP</emphasis> Getting the console straight away
fa-IR: <emphasis>نکته</emphasis> دسترسی مستقیم به کنسول

en: Sometimes one wishes to start a domU system and get to its console straight away; this is why the <command>xl create</command> command takes a <literal>-c</literal> switch. Starting a domU with this switch will display all the messages as the system boots.
fa-IR: بعضی وقت‌ها شاید بخواهیم پس از راه‌اندازی سیستم domU مستقیم وارد کنسول آن شویم؛ به همین دلیل است که دستور <command>xl create</command> یک گزینه <literal>-c</literal> را نیز می‌پذیرد. آغاز یک domU همراه با این سوئیچ تمام پیام‌های موجود هنگام راه‌اندازی آن را نمایش می‌دهد.

en: Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the <command>xl pause</command> and <command>xl unpause</command> commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the <command>xl save</command> and <command>xl restore</command> commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.
fa-IR: زمانی که domU آغاز گردد، می‌تواند مانند هر سرور دیگری مورد استفاده قرار گیرد (چرا که یک سیستم گنو/لینوکس است). اگرچه، وضعیت ماشین مجازی آن برخی قابلیت‌های دیگر را فراهم می‌کند. برای نمونه، یک domU با استفاده از دستورات <command>xl pause</command> و <command>xl unpause</command> می‌تواند به صورت موقت متوقف شده یا ادامه یابد. به یاد داشته باشید که یک domU متوقف شده با اینکه از قدرت پردازنده استفاده نمی‌کند، اما هم اکنون حافظه اختصاص یافته به خود را دارد. استفاده از دستورات <command>xl save</command> و <command>xl restore</command> نیز قابل توجه است: ذخیره‌سازی یک domU تمام منابع اختصاص یافته به آن، از جمله RAM، را آزادسازی می‌کند. در زمان بازگرداندن (یا ادامه، به این منظور) یک domU چیزی به جز گذشت زمان را احساس نمی‌کند. اگر هنگام خاموش کردن dom0 یک domU در حال اجرا باشد، اسکریپت‌های پیکربندی به صورت خودکار domU را ذخیره‌سازی کرده تا در راه‌اندازی بعدی از سر گرفته شود. این عمل البته ناملایمت‌های عملیات hibernate کردن یک رایانه لپ‌تاپ را به همراه دارد، برای نمونه؛ به طور مشخص اگر domU به مدت زمان طولانی در حالت تعلیق باشد، ارتباطات شبکه ممکن است منقضی گردند. به یاد داشته باشید که Xen به شدت ناسازگار با بخش مدیریت قدرت ACPI است، که عملیات متوقف‌سازی سیستم میزبان (dom0) را انجام می‌دهد.

en: Halting or rebooting a domU can be done either from within the domU (with the <command>shutdown</command> command) or from the dom0, with <command>xl shutdown</command> or <command>xl reboot</command>.
fa-IR: متوقف‌سازی یا راه‌اندازی مجدد یک domU می‌تواند از طریق خود آن (با دستور <command>shutdown</command>) یا از طریق dom0 با استفاده از <command>xl shutdown</command> یا <command>xl reboot</command> انجام شود.

en: Most of the <command>xl</command> subcommands expect one or more arguments, often a domU name. These arguments are well described in the <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> manual page.
fa-IR: اغلب زیردستورات <command>xl</command> شامل یک یا چند آرگومان هستند، که بیشتر شامل نام یک domU می‌شود. این آرگومان‌ها به خوبی در صفحه راهنمای <citerefentry><refentrytitle>xl</refentrytitle> <manvolnum>1</manvolnum></citerefentry> توضیح داده شده‌اند.

en: <emphasis>GOING FURTHER</emphasis> Advanced Xen
fa-IR: <emphasis>مطالعه بیشتر</emphasis> Xen پیشرفته

en: Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as <emphasis>control groups</emphasis>, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.
fa-IR: با اینکه از آن برای ساخت “ماشین‌های مجازی” استفاده می‌شود، LXC به طور دقیق یک سیستم مجازی‌سازی نیست، بلکه سیستمی برای جدا کردن گروهی از فرآیندها نسبت به یکدیگر می‌باشد که درون یک میزبان اجرا می‌شوند. این سیستم از پیشرفت‌های اخیر در کرنل لینوکس بهره می‌برد، که بنام <emphasis>گروه‌های کنترل</emphasis> شناخته می‌شوند، به این معنی که مجموعه‌های مختلف از فرآیندها که “گروه” نامیده می‌شوند دید متفاوتی نسبت به جنبه‌های کلی سیستم دارند. از جمله این جنبه‌ها می‌توان به شناسه‌های فرآیند، پیکربندی شبکه و نقاط اتصال اشاره کرد. چنین گروهی از فرآیندهای ایزوله‌شده هیچ گونه دسترسی دیگر به سایر فرآیندهای سیستم ندارند و دسترسی آن‌ها به فایل سیستم تنها محدود به مجموعه‌ای کوچک می‌گردد. از این رو می‌تواند رابط شبکه و جدول مسیریابی مربوط به خود را داشته باشد و می‌تواند طوری پیکربندی شود که تنها مجموعه کوچکی از دستگاه‌های موجود در سیستم را مشاهده کند.

en: <emphasis>NOTE</emphasis> LXC isolation limits
fa-IR: <emphasis>یادداشت</emphasis> محدودیت‌های انزوای LXC

en: LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:
fa-IR: مخازن LXC سطحی از انزوا را مانند شبیه‌سازهای قدرتمند یا مجازی‌سازهای دیگر فراهم نمی‌کنند. به طور مشخص:

en: since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;
fa-IR: از آنجا که کرنل بین سیستم میزبان و مخازن مشترک است، فرآیندهایی که محدود به مخازن هستند کماکان می‌توانند به پیام‌های کرنل دسترسی داشته باشند که در صورت انتشار پیام‌ها توسط یک مخزن می‌تواند منجر به افشای اطلاعات شود؛

en: for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;
fa-IR: به دلیل مشابه، اگر به یک مخزن نفوذ شود و از یک آسیب‌پذیری کرنل استفاده گردد، سایر مخازن نیز تاثیر منفی می‌پذیرند؛

en: on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.
fa-IR: در فایل سیستم، کرنل به بررسی مجوزهای کاربران و گروه‌ها مبتنی بر شناسه‌های عددی می‌پردازد؛ این شناسه‌ها ممکن است به کاربران و گروه‌های مختلف با توجه به مخزن اختصاص یابند که در صورت اشتراکی بودن قسمت‌های قابل نوشتن فایل سیستم بین مخازن باید مورد توجه قرار گیرد.

en: Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.
fa-IR: از آنجا که با مفهوم ایزوله کردن و نه یک راهکار مجازی‌سازی ساده سروکار داریم، برپایی مخازن LXC بسیار پیچیده‌تر از اجرای debian-installer در یک ماشین مجازی است. ابتدا چندین پیشنیاز را بررسی کرده سپس به قسمت پیکربندی شبکه می‌رویم؛ در این قسمت است که می‌توانیم سیستم را درون یک مخزن اجرا کنیم.

en: Preliminary Steps
fa-IR: گام‌های مقدماتی

en: The <emphasis role="pkg">lxc</emphasis> package contains the tools required to run LXC, and must therefore be installed.
fa-IR: بسته <emphasis role="pkg">lxc</emphasis> شامل ابزار مورد نیاز برای نصب و اجرای LXC است.

en: LXC also requires the <emphasis>control groups</emphasis> configuration system, which is a virtual filesystem to be mounted on <filename>/sys/fs/cgroup</filename>. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.
fa-IR: LXC همچنین به سیستم پیکربندی <emphasis>control groups</emphasis> نیاز دارد که به صورت یک فایل سیستم مجازی به <filename>/sys/fs/cgroup</filename> متصل می‌شود. از آنجا که دبیان ۸ به systemd روی آورده، که خود مبتنی بر گروه‌های کنترل است، اینکار در زمان راه‌اندازی سیستم بدون هیچ پیکربندی خاص صورت می‌گیرد.

en: Network Configuration
fa-IR: پیکربندی شبکه

en: They should be disabled and replaced with the following:
fa-IR: آن‌ها باید غیرفعال شده و با مدخل‌های زیر جایگزین گردند:

en: The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical <literal>eth0</literal> as well as the interfaces defined for the containers.
fa-IR: تاثیر این پیکربندی مشابه با حالتی خواهد بود که مخازن به صورت ماشین‌هایی به شبکه فیزیکی یکسانی از طریق میزبان متصل می‌شدند. پیکربندی “bridge” انتقال فریم‌های Ethernet را بین تمام رابط‌های bridged مدیریت می‌کند که شامل <literal>eth0</literal> همراه با رابط‌های تعریف شده برای مخازن می‌باشد.

en: In addition to <emphasis role="pkg">bridge-utils</emphasis>, this “rich” configuration requires the <emphasis role="pkg">vde2</emphasis> package; the <filename>/etc/network/interfaces</filename> file then becomes:
fa-IR: علاوه بر <emphasis role="pkg">bridge-utils</emphasis>، این پیکربندی “غنی” نیازمند بسته <emphasis role="pkg">vde2</emphasis> است؛ فایل <filename>/etc/network/interfaces</filename> سپس به صورت زیر در می‌آید:

en: The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the <literal>br0</literal> interface.
fa-IR: شبکه می‌تواند یا به صورت ایستا درون مخازن یا به صورت پویا از طریق سرور DHCP درون میزبان برپا شود. چنین سرور DHCP باید طوری پیکربندی شود که به پرس و جوهای موجود در رابط <literal>br0</literal> پاسخ دهد.

en: Setting Up the System
fa-IR: برپایی سیستم

en: Note that the filesystem is initially created in <filename>/var/cache/lxc</filename>, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.
fa-IR: به یاد داشته باشید که فایل سیستم به صورت اولیه در <filename>/var/cache/lxc</filename> ایجاد شد، سپس به مقصد خود انتقال یافت. اینکار امکان ایجاد مخازن مشابه را با سرعت بیشتری فراهم می‌کند، چرا که تنها عملیات رونوشت‌گیری مورد نیاز است.

en: Another useful entry in that file is the setting of the hostname:
fa-IR: یک مدخل مفید دیگر در آن فایل تنظیم نام میزبان است:

en: Starting the Container
fa-IR: آغاز مخزن

en: We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (<filename>/var/lib/lxc/testlxc/rootfs</filename>). We can exit the console with <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo>.
fa-IR: اکنون درون مخزن هستیم؛ دسترسی به فرآیندها تنها محدود به آن‌هایی است که توسط مخزن آغاز شده باشند و دسترسی به فایل سیستم تنها بخش کوچکی از فایل سیستم کامل <filename>/var/lib/lxc/testlxc/rootfs</filename> را شامل می‌شود. با استفاده از کلید ترکیبی <keycombo action="simul"><keycap>Control</keycap> <keycap>a</keycap></keycombo> <keycombo><keycap>q</keycap></keycombo> می‌توانیم از کنسول خارج شویم.

en: The <emphasis role="pkg">lxc</emphasis> package contains an initialization script that can automatically start one or several containers when the host boots (it relies on <command>lxc-autostart</command> which starts containers whose <literal>lxc.start.auto</literal> option is set to 1). Finer-grained control of the startup order is possible with <literal>lxc.start.order</literal> and <literal>lxc.group</literal>: by default, the initialization script first starts containers which are part of the <literal>onboot</literal> group and then the containers which are not part of any group. In both cases, the order within a group is defined by the <literal>lxc.start.order</literal> option.
fa-IR: بسته <emphasis role="pkg">lxc</emphasis> شامل یک اسکریپت راه‌اندازی است که به صورت خودکار یک یا چند مخزن را در زمان راه‌اندازی میزبان آغاز می‌کند (مبتنی بر <command>lxc-autostart</command> است که به صورت خودکار مخازن شامل گزینه <literal>lxc.start.auto</literal> برابر ۱ را راه‌اندازی می‌کند). با استفاده از <literal>lxc.start.order</literal> و <literal>lxc.group</literal> می‌توان کنترل بیشتری روی ترتیب اجرای مخازن اعمال کرد: به صورت پیشفرض، اسکریپت راه‌اندازی ابتدا مخازنی را آغاز می‌کند که جزو گروه <literal>onboot</literal> باشند سپس به سراغ مخازن دیگر می‌رود). در هر دو مورد، ترتیب درون هر گروه توسط گزینه <literal>lxc.start.order</literal> مشخص می‌شود.

en: <emphasis>GOING FURTHER</emphasis> Mass virtualization
fa-IR: <emphasis>مطالعه بیشتر</emphasis> مجازی‌سازی انبوه

en: Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using <literal>tap</literal> and <literal>veth</literal> interfaces should be enough in many cases.
fa-IR: از آنجا که LXC یک سیستم ایزوله‌کردن سبک به حساب می‌آید، می‌تواند به منظور میزبانی از سرورهای مجازی انبوه سازگار شود. پیکربندی شبکه از آنچه در این قسمت توضیح دادیم به مراتب پیچیده‌تر خواهد بود اما پیکربندی “غنی” با استفاده از رابط‌های <literal>tap</literal> و <literal>veth</literal> در اکثر موارد به شیوه توضیح داده شده کافی خواهد بود.

en: It may also make sense to share part of the filesystem, such as the <filename>/usr</filename> and <filename>/lib</filename> subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with <literal>lxc.mount.entry</literal> entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.
fa-IR: به منظور پیشگیری از نصب مجدد نرم‌افزارهایی که برای چندین مخزن کاربردی هستند، معقول بنظر می‌رسد که قسمتی از فایل سیستم مانند <filename>/usr</filename> و <filename>/lib</filename> را به اشتراک بگذاریم. اینکار معمولا با مدخل‌های <literal>lxc.mount.entry</literal> درون فایل پیکربندی مخازن انجام می‌شود. یک تاثیر جانبی جالب این است که فرآیندها از حافظه فیزیکی کمتری استفاده می‌کنند، چرا که کرنل قادر به تشخیص برنامه‌هایی است که به صورت اشتراکی کار می‌کنند. هزینه حاشیه‌ای یک مخزن اضافی دیگر می‌تواند به فضای دیسک اختصاص یافته به داده خاص و چند فرآیند اضافی که کرنل برای زمان‌بندی و مدیریت استفاده می‌کند، کاهش یابد.

en: We haven't described all the available options, of course; more comprehensive information can be obtained from the <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> and <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual pages and the ones they reference.
fa-IR: البته، تمام گزینه‌های موجود را بررسی نکردیم؛ اطلاعات جامع بیشتر از طریق صفحات راهنمای <citerefentry> <refentrytitle>lxc</refentrytitle> <manvolnum>7</manvolnum> </citerefentry> و <citerefentry> <refentrytitle>lxc.container.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> همراه با سایر مراجع آن قابل دسترس است.

en: Virtualization with KVM
fa-IR: مجازی‌سازی با KVM

en: KVM, which stands for <emphasis>Kernel-based Virtual Machine</emphasis>, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions <command>qemu-*</command> commands: it is still about KVM.
fa-IR: KVM، که مخفف عبارت <emphasis>Kernel-based Virtual Machine</emphasis> است، در درجه اول یک افزونه کرنل به حساب می‌آید که اکثر زیرساخت مورد نیاز یک مجازی‌ساز را فراهم می‌کند اما خود یک مجازی‌ساز نیست. کنترل واقعی مجازی‌سازی توسط برنامه‌ای مبتنی بر QEMU انجام می‌شود. نگران نباشید اگر در این قسمت دستورات مربوط به <command>qemu-*</command> را مشاهده کنید: تمام آن‌ها مرتبط با KVM هستند.

en: Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in <filename>/proc/cpuinfo</filename>.
fa-IR: برخلاف سایر سیستم‌های مجازی‌سازی، KVM از ابتدا درون کرنل لینوکس قرار گرفت. توسعه‌دهندگان آن تصمیم گرفتند از مجموعه دستورالعمل‌های پردازنده برای مجازی‌سازی (Intel-VT و AMD-V) استفاده کنند که اینکار باعث می‌شود KVM سبک، ظریف و سازگار با منابع پایین باشد. نقطه ضعف آن این است که KVM روی هر رایانه‌ای نمی‌تواند اجرا شود بلکه فقط برخی پردازنده‌های خاص از آن پشتیبانی می‌کنند. برای رایانه‌های مبتنی بر x86، می‌توانید به دنبال پرچم‌های مخصوص پردازنده به نام “vmx” یا “svm” در فایل <filename>/proc/cpuinfo</filename> بگردید.

en: With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.
fa-IR: با پشتیبانی مداوم Red Hat از توسعه آن، KVM کم و بیش به مرجع مجازی‌سازی در لینوکس تبدیل شده است.

en: The <emphasis role="pkg">virtinst</emphasis> package provides <command>virt-install</command>, which allows creating virtual machines from the command line. Finally, <emphasis role="pkg">virt-viewer</emphasis> allows accessing a VM's graphical console.
fa-IR: بسته <emphasis role="pkg">virtinst</emphasis> شامل <command>virt-install</command> می‌شود که امکان ایجاد ماشین‌های مجازی از خط فرمان را فراهم می‌کند. در نهایت، <emphasis role="pkg">virt-viewer</emphasis> اجازه دسترسی به کنسول گرافیکی یک ماشین مجازی را بوجود می‌آورد.

en: Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see <xref linkend="sect.lxc.network" />).
fa-IR: درست مانند Xen و LXC، متداول‌ترین پیکربندی شبکه شامل یک bridge که رابط‌های شبکه ماشین‌های مجازی را گروه‌بندی می‌کند، می‌باشد (<xref linkend="sect.lxc.network" /> را مشاهده کنید).

en: Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.
fa-IR: به طور متقابل، در پیکربندی پیشفرض فراهم شده توسط KVM، یک نشانی خصوصی به ماشین مجازی اختصاص می‌یابد (در محدوده 192.168.122.0/24) و NAT طوری تنظیم می‌شود که ماشین مجازی بتواند به شبکه خارجی دسترسی داشته باشد.

en: The rest of this section assumes that the host has an <literal>eth0</literal> physical interface and a <literal>br0</literal> bridge, and that the former is connected to the latter.
fa-IR: باقیمانده این قسمت با توجه به اینکه میزبان دارای یک رابط فیزیکی <literal>eth0</literal> و bridge <literal>br0</literal> است ادامه می‌یابد، به طوری که اولی به دومی متصل شده است.

en: Installation with <command>virt-install</command>
fa-IR: نصب با <command>virt-install</command>

en: Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.
fa-IR: ایجاد یک ماشین مجازی بسیار شبیه یک سیستم عادی است، با این تفاوت که ویژگی‌های ماشین مجازی به صورت گزینه‌های بی‌پایان در خط فرمان قرار می‌گیرند.

en: Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see <xref linkend="sect.remote-desktops" /> for details), which will allow us to control the installation process.
fa-IR: در عمل، یعنی از یک نصب کننده دبیان استفاده خواهیم کرد، با راه‌اندازی ماشین مجازی روی یک درایو DVD-ROM که به یک تصویر از DVD دبیان ذخیره شده در سیستم میزبان نگاشت شده است. ماشین مجازی از طریق پروتکل VNC کنسول گرافیکی خود را آماده می‌کند (<xref linkend="sect.remote-desktops" /> را مشاهده کنید) که اینکار به ما اجازه می‌دهد فرآیند نصب را کنترل کنیم.

en: <emphasis>TIP</emphasis> Add your user to the libvirt group
fa-IR: <emphasis>نکته</emphasis> افزودن کاربر خود به گروه libvirt

en: Let us now start the installation process for the virtual machine, and have a closer look at <command>virt-install</command>'s most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.
fa-IR: اکنون بیایید فرآیند نصب ماشین مجازی را آغاز کرده و نگاهی بر مهم‌ترین گزینه‌های <command>virt-install</command> بیندازیم. این دستور، ماشین مجازی و پارامترهای آن را در libvirtd ثبت می‌کند سپس به اجرای آن پرداخته تا فرآیند نصب ادامه یابد.

en: The <literal>--connect</literal> option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (<literal>xen://</literal>, <literal>qemu://</literal>, <literal>lxc://</literal>, <literal>openvz://</literal>, <literal>vbox://</literal>, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (<literal>/system</literal>) from others (<literal>/session</literal>).
fa-IR: گزینه <literal>--connect</literal> مشخص می‌کند از کدام “hypervisor” استفاده شود. فرم استفاده از آن شامل یک URL همراه با سیستم مجازی‌سازی مرتبط (<literal>xen://</literal>، <literal>qemu://</literal>، <literal>lxc://</literal>، <literal>openvz://</literal>، <literal>vbox://</literal>) و ماشینی که باید از آن میزبانی کند می‌باشد (در صورت استفاده از localhost می‌تواند خالی باشد). علاوه بر این و در مورد QEMU/KVM، هر کاربر می‌تواند با استفاده از مجوزهای محدودشده ماشین‌های مجازی را مدیریت کند و مسیر URL امکان تفاوت قائل شدن بین ماشین‌های “سیستم” (<literal>/system</literal>) را از دیگر (<literal>/session</literal>) فراهم می‌کند.

en: Since KVM is managed the same way as QEMU, the <literal>--virt-type kvm</literal> allows specifying the use of KVM even though the URL looks like QEMU.
fa-IR: از آنجا که KVM به شیوه مشابه QEMU مدیریت می‌شود، <literal>--virt-type kvm</literal> امکان مشخص کردن استفاده از KVM با وجود تشابه با URL QEMU را فراهم می‌کند.

en: The <literal>--name</literal> option defines a (unique) name for the virtual machine.
fa-IR: گزینه <literal>--name</literal> یک نام (منحصربفرد) برای ماشین مجازی تعریف می‌کند.

en: The <literal>--cdrom</literal> option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. <literal>/dev/cdrom</literal>).
fa-IR: گزینه <literal>--cdrom</literal> به منظور یافتن دیسک نوری برای فرآیند نصب استفاده می‌شود. مسیر می‌تواند شامل یک مسیر محلی برای فایل ISO، یک URL که فایل می‌تواند از آنجا دریافت شود یا فایل دستگاه مربوط به یک درایو فیزیکی CD-ROM باشد (<literal>/dev/cdrom</literal>).

en: The <literal>--network</literal> specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).
fa-IR: گزینه <literal>--network</literal> مشخص می‌کند کارت مجازی شبکه چطور با پیکربندی سیستم میزبان ادغام شود. عملکرد پیشفرض آن (که در این نمونه به صورت صریح بیان کرده‌ایم) ادغام آن با شبکه bridge از قبل موجود در سیستم است. اگر چنین bridge موجود نباشد، ماشین مجازی تنها با استفاده از NAT می‌تواند به شبکه فیزیکی دسترسی یابد، بنابراین یک نشانی در محدوده زیرشبکه 192.168.122.0/24 دریافت می‌کند.

en: The <literal>--os-type</literal> and <literal>--os-variant</literal> options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.
fa-IR: گزینه‌های <literal>--os-type</literal> و <literal>--os-variant</literal>، با توجه به برخی از ویژگ‌های سیستم عامل اشاره شده، امکان بهینه‌سازی چندین پارامتر ماشین مجازی را فراهم می‌کنند.

en: At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, <command>virt-viewer</command> can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):
fa-IR: در این نقطه، ماشین مجازی در حال اجرا است و به منظور ادامه فرآیند نصب باید به کنسول گرافیکی متصل شویم. اگر عملیات قبل از طریق یک میزکار گرافیکی صورت گرفته باشد، این ارتباط به صورت مستقیم برقرار می‌شود. در غیر اینصورت، یا در حالتی که از راه دور اینکار را انجام می‌دهیم، <command>virt-viewer</command> با استفاده از هر محیط گرافیکی برای باز کردن کنسول گرافیکی می‌تواند اجرا شود (به یاد داشته باشید که دو مرتبه گذرواژه root درخواست می‌شود چرا که ۲ ارتباط SSH مورد نیاز است):

en: When the installation process ends, the virtual machine is restarted, now ready for use.
fa-IR: زمانی که فرآیند نصب به پایان برسد، ماشین مجازی راه‌اندازی مجدد می‌گردد تا قابل استفاده شود.

en: Managing Machines with <command>virsh</command>
fa-IR: مدیریت ماشین‌های مجازی با <command>virsh</command>

en: Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask <command>libvirtd</command> for the list of the virtual machines it manages:
fa-IR: اکنون که نصب به پایان رسیده است، بیایید چگونگی مدیریت ماشین‌های مجازی را بررسی کنیم. اولین کاری که باید بکنیم پرسش از <command>libvirtd</command> برای فهرستی از ماشین‌های مجازی موجود است:

en: Let's start our test virtual machine:
fa-IR: بیایید ماشین مجازی آزمایشی خود را آغاز کنیم:

en: We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to <command>vncviewer</command>):
fa-IR: اکنون می‌توانیم دستورالعمل‌های ارتباط به کنسول گرافیکی را دریافت کنیم (نمایش VNC بازگشتی می‌تواند به عنوان پارامتر <command>vncviewer</command> استفاده شود):

en: Other available <command>virsh</command> subcommands include:
fa-IR: سایر دستورات <command>virsh</command> عبارتند از:

en: <literal>reboot</literal> to restart a virtual machine;
fa-IR: <literal>reboot</literal> برای راه‌اندازی مجدد یک ماشین مجازی؛

en: <literal>shutdown</literal> to trigger a clean shutdown;
fa-IR: <literal>shutdown</literal> برای درخواست یک shutdown تمیز؛

en: <literal>destroy</literal>, to stop it brutally;
fa-IR: <literal>destroy</literal> برای توقف خشن آن؛

en: <literal>suspend</literal> to pause it;
fa-IR: <literal>suspend</literal> برای توقف عادی آن؛

en: <literal>resume</literal> to unpause it;
fa-IR: <literal>resume</literal> برای ادامه فعالیت آن؛

en: <literal>autostart</literal> to enable (or disable, with the <literal>--disable</literal> option) starting the virtual machine automatically when the host starts;
fa-IR: <literal>autostart</literal> برای فعال کردن (یا غیر فعال کردن با گزینه <literal>--disable</literal>) راه‌اندازی ماشین مجازی به صورت خودکار در زمان راه‌اندازی میزبان؛

en: <literal>undefine</literal> to remove all traces of the virtual machine from <command>libvirtd</command>.
fa-IR: <literal>undefine</literal> برای حذف تمام نشانه‌های ماشین مجازی از <command>libvirtd</command>.

en: All these subcommands take a virtual machine identifier as a parameter.
fa-IR: تمام این دستورات شناسه ماشین مجازی را به عنوان یک پارامتر دریافت می‌کنند.

en: Automated Installation
fa-IR: نصب خودکار

en: <primary>deployment</primary>
fa-IR: <primary>گسترش</primary>

en: <primary>installation</primary><secondary>automated installation</secondary>
fa-IR: <primary>نصب</primary><secondary>نصب خودکار</secondary>

en: The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.
fa-IR: مدیر سیستم‌های شرکت فالکوت، مانند سایر مدیر سیستم‌های خدمات بزرگ IT، به ابزاری نیاز دارند که فرآیند نصب (یا بازنصب) ماشین‌های خود را در کمترین زمان و در صورت ممکن به صورت خودکار انجام دهند.

en: These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (<emphasis>Fully Automatic Installer</emphasis>) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).
fa-IR: این نیازمندی‌ها توسط طیف گسترده‌ای از راه حل‌ها برطرف می‌شوند. از یک طرف ابزار عمومی مانند SystemImager با ایجاد یک تصویر از ماشین نمونه، آن را روی ماشین‌های هدف گسترش می‌دهد؛ از طرف دیگر، نصب کننده دبیان این قابلیت را دارد که با استفاده از یک فایل پیکربندی خاص به پرسش‌های مطرح شده طی فرآیند نصب به صورت خودکار پاسخ دهد. به عنوان یک راه حل ترکیبی، ابزاری مانند FAI، که مخفف <emphasis>Fully Automatic Installer</emphasis> است، ماشین‌ها را با استفاده از سیستم بسته‌بندی نصب، اما از زیرساخت خود به منظور فرآیندهای پیچیده‌تر مانند راه‌اندازی، پارتیشن‌بندی و پیکربندی استفاده می‌کند.

en: Fully Automatic Installer (FAI)
fa-IR: نصب‌کننده تمام خودکار (FAI)

en: <foreignphrase>Fully Automatic Installer</foreignphrase> is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.
fa-IR: <foreignphrase>نصب‌کننده تمام خودکار</foreignphrase> احتمالا قدیمی‌ترین سیستم گسترش خودکار برای دبیان باشد، که جایگاه آن به عنوان یک مرجع را مشخص می‌کند؛ اما طبیعت بسیار سازگار آن به نوعی پیچیدگی‌های درونی‌اش را جبران می‌کند.

en: FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the <emphasis role="pkg">fai-server</emphasis> package (or <emphasis role="pkg">fai-quickstart</emphasis>, which also brings the required elements for a standard configuration).
fa-IR: FAI نیازمند یک سیستم سرور به منظور نگهداری از اطلاعات راه‌اندازی برای ماشین‌های است که قصد دارند از طریق شبکه به آن متصل گردند. این سرور نیازمند بسته <emphasis role="pkg">fai-server</emphasis> (یا <emphasis role="pkg">fai-quickstart</emphasis>، که عناصر مورد نیاز برای یک پیکربندی استاندارد را گردآوری می‌کند) است.

en: Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:
fa-IR: ایجاد تمام این فایل‌های پیکربندی نیازمند درک درستی از چگونگی عملکرد FAI می‌باشد. یک فرآیند متداول نصب از گام‌های زیر تشکیل شده است:

en: fetching a kernel from the network, and booting it;
fa-IR: دریافت یک کرنل از شبکه و راه‌اندازی آن؛

en: mounting the root filesystem from NFS;
fa-IR: اتصال فایل سیستم root از NFS؛

en: executing <command>/usr/sbin/fai</command>, which controls the rest of the process (the next steps are therefore initiated by this script);
fa-IR: اجرای <command>/usr/sbin/fai</command>، که باقی فرآیند نصب را کنترل می‌کند (از این رو گام‌های بعدی توسط این اسکریپت فراخوانی می‌شوند)؛

en: copying the configuration space from the server into <filename>/fai/</filename>;
fa-IR: رونوشت‌گیری فضای پیکربندی از سرور درون <filename>/fai/</filename>؛

en: running <command>fai-class</command>. The <filename>/fai/class/[0-9][0-9]*</filename> scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.
fa-IR: اجرای <command>fai-class</command>. اسکریپت‌های <filename>/fai/class/[0-9][0-9]*</filename> به ترتیب اجرا می‌شوند و نام “کلاس‌های” منطبق با ماشین مورد نظر می‌باشند را بر می‌گردانند؛ از این اطلاعات برای ادامه فرآیند نصب استفاده می‌شود. اینکار موجب انعطاف‌پذیری در تعریف سرویس‌های مورد نیاز برای نصب و پیکربندی می‌شود.

en: fetching a number of configuration variables, depending on the relevant classes;
fa-IR: دریافت تعدادی از متغیرهای پیکربندی، با توجه به کلاس‌های مربوطه؛

en: partitioning the disks and formatting the partitions, based on information provided in <filename>/fai/disk_config/<replaceable>class</replaceable></filename>;
fa-IR: پارتیشن‌بندی دیسک‌ها و فرمت کردن پارتیشن‌ها، بر اساس اطلاعات فراهم شده در <filename>/fai/disk_config/<replaceable>class</replaceable></filename>؛

en: mounting said partitions;
fa-IR: اتصال پارتیشن‌های مذکور؛

en: installing the base system;
fa-IR: نصب سیستم پایه؛

en: preseeding the Debconf database with <command>fai-debconf</command>;
fa-IR: گردآوری پایگاه‌داده Debconf با استفاده از <command>fai-debconf</command>؛

en: fetching the list of available packages for APT;
fa-IR: دریافت فهرست بروزرسانی‌های موجود برای APT؛

en: installing the packages listed in <filename>/fai/package_config/<replaceable>class</replaceable></filename>;
fa-IR: نصب بسته‌های فهرست شده در <filename>/fai/package_config/<replaceable>class</replaceable></filename>؛

en: executing the post-configuration scripts, <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>;
fa-IR: اجرای اسکریپت‌های پس از پیکربندی، <filename>/fai/scripts/<replaceable>class</replaceable>/[0-9][0-9]*</filename>؛

en: recording the installation logs, unmounting the partitions, and rebooting.
fa-IR: ثبت گزارش‌های نصب، قطع اتصال پارتیشن‌ها و راه‌اندازی مجدد.

en: Preseeding Debian-Installer
fa-IR: گردآوری debian-installer

en: <emphasis>GOING FURTHER</emphasis> Debconf with a centralized database
fa-IR: <emphasis>مطالعه بیشتر</emphasis> Debconf همراه با یک پایگاه‌داده مرکزی

en: Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the <filename>/etc/debconf.conf</filename> configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> manual page describes all the possibilities in detail (you need the <emphasis role="pkg">debconf-doc</emphasis> package).
fa-IR: Preseeding امکان فراهم کردن مجموعه‌ای از پاسخ‌ها به پرسش‌های Debconf در زمان نصب را می‌دهد، اما این پاسخ‌ها ایستا بوده و در گذر زمان تغییر نمی‌کنند. از آنجا که ماشین‌های نصب-شده نیازمند بروزرسانی هستند و ممکن است به پاسخ‌های جدید نیاز باشد، فایل پیکربندی <filename>/etc/debconf.conf</filename> می‌تواند به منظور استفاده Debconf از منابع خارجی داده (مانند یک دایرکتوری سرور LDAP یا فایلی که از طریق NFS یا Samba مورد نیاز باشد)، پیکربندی شود. منابع داده خارجی متفاوتی می‌توانند در یک زمان تعریف شوند تا یکدیگر را کامل کنند. پایگاه‌داده محلی به منظور دسترسی خواندنی-نوشتنی و پایگاه‌داده‌های راه دور به منظور دسترسی فقط-خواندنی محدود می‌شوند. صفحه راهنمای <citerefentry><refentrytitle>debconf.conf</refentrytitle> <manvolnum>5</manvolnum></citerefentry> به تشریح تمام احتمالات موجود در این زمینه می‌پردازد (به بسته <emphasis role="pkg">debconf-doc</emphasis> نیاز دارید).

en: Using a Preseed File
fa-IR: استفاده از یک فایل Preseed

en: There are several places where the installer can get a preseeding file:
fa-IR: مکان‌های مختلفی وجود دارد که یک نصب‌کننده می‌تواند فایل preseed را دریافت کند:

en: in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called <filename>preseed.cfg</filename> and stored in the initrd root.
fa-IR: در initrd که برای راه‌اندازی ماشین استفاده شده است؛ در این مورد، عملیات preseed در ابتدای فرآیند نصب صورت می‌گیرد و تمام پرسش‌ها می‌توانند نادیده گرفته شوند. این فایل باید بنام <filename>preseed.cfg</filename> در اولین سطح دایرکتوری initrd قرار گیرد.

en: on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The <literal>preseed/file</literal> boot parameter can be used to indicate the location of the preseeding file (for instance, <filename>/cdrom/preseed.cfg</filename> when the installation is done off a CD-ROM, or <filename>/hd-media/preseed.cfg</filename> in the USB-key case).
fa-IR: در رسانه راه‌اندازی (مانند CD یا USB)؛ عملیات preseed به محض اتصال رسانه صورت می‌گیرد، یعنی درست پس از پرسش‌های مربوط به زبان و ساختار صفحه کلید. پارامتر راه‌اندازی <literal>preseed/file</literal> می‌تواند برای شناسایی مکان فایل preseed (برای نمونه، <filename>/cdrom/preseed.cfg</filename> در هنگام نصب از CD-ROM یا <filename>/hd-media/preseed.cfg</filename> در هنگام نصب از USB) مورد استفاده قرار گیرد.

en: At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for <command>isolinux</command> (in the CD-ROM case) or <command>syslinux</command> (USB key).
fa-IR: در یک نگاه، قرار دادن فایل preseed درون initrd ممکن است جالب‌ترین گزینه به نظر آید؛ اگرچه، کمتر از این حالت استفاده می‌شود چرا که ایجاد یک initrd قابل نصب بسیار دشوار است. دو راهکار جایگزین دیگر، بیشتر متداول هستند، به خصوص که پارامترهای راه‌اندازی روشی دیگر برای آماده‌سازی پاسخ‌ها به اولین پرسش‌های فرآیند نصب را فراهم می‌کنند. روش مرسوم برای ذخیره‌سازی این پارامترهای راه‌اندازی و جلوگیری از نوشتن هر کدام در زمان نصب، قرار دادن آن‌ها در پیکربندی مرتبط با <command>isolinux</command> (در مورد CD-ROM) یا <command>syslinux</command> (در مورد USB) است.

en: Creating a Preseed File
fa-IR: ایجاد یک فایل Preseed

en: A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, <literal>d-i mirror/suite string stable</literal>:
fa-IR: یک فایل preseedاز نوع متنی است که در هر خط آن پاسخ به یک پرسش از Debconf قرار دارد. هر خط به چهار فیلد که با فاصله (space یا tab) از یکدیگر جدا می‌شوند، تقسیم شده است. برای نمونه، در مورد <literal>d-i mirror/suite string stable</literal>:

en: the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;
fa-IR: فیلد اول “مالک” پرسش به حساب می‌آید؛ “d-i” برای پرسش‌هایی استفاده می‌شود که مرتبط با فرآیند نصب هستند، اما می‌تواند در مورد  نام بسته‌های موجود دبیان نیز بکار رود؛

en: third, the type of question;
fa-IR: فیلد سوم نوع پرسش را مشخص می‌کند؛

en: the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.
fa-IR: فیلد چهارم و آخرین فیلد نیز پاسخ به پرسش را شامل می‌شود. به یاد داشته باشید که از فیلد سوم توسط یک space باید جدا شود؛ اگر بیش از یک فاصله بکار رود، به عنوان بخشی از پاسخ در نظر گرفته می‌شود.

en: The simplest way to write a preseed file is to install a system by hand. Then <command>debconf-get-selections --installer</command> will provide the answers concerning the installer. Answers about other packages can be obtained with <command>debconf-get-selections</command>. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the <literal>priority=critical</literal> boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.
fa-IR: ساده‌ترین روش برای ایجاد یک فایل preseed نصب یک سیستم به صورت دستی است. سپس <command>debconf-get-selections --installer</command> پاسخ‌های مرتبط با آن را فراهم می‌کند. پاسخ‌های مرتبط با سایر بسته‌ها نیز توسط <command>debconf-get-selections</command> گردآوری می‌شوند. اگرچه، راهکار بهتر در این مورد نوشتن فایل preseed به صورت دستی است، که از یک فایل نمونه و مستندات مرجع می‌توان استفاده کرد: با چنین رویکردی، تنها پرسش‌هایی که پاسخ‌های پیشفرض داشته باشند می‌توانند آماده‌سازی شوند؛ استفاده از پارامتر راه‌اندازی <literal>priority=critical</literal> به Debconf دستور می‌دهد که تنها به پرسش‌های حیاتی پاسخ دهد و از پاسخ‌های پیشفرض برای سایر پرسش‌ها استفاده کند.

en: <emphasis>DOCUMENTATION</emphasis> Installation guide appendix
fa-IR: <emphasis>مستندات</emphasis> ضمیمه راهنمای نصب

en: Creating a Customized Boot Media
fa-IR: ایجاد یک رسانه راه‌اندازی سفارشی‌

en: Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.
fa-IR: دانستن اینکه یک فایل preseed در کجا ذخیره شود خوب است، اما کافی نیست: مدیر سیستم باید به شیوه‌ای رسانه‌ راه‌اندازی نصب را تغییر دهد که پارامترهای راه‌اندازی تغییر کرده و فایل preseed به آن اضافه شود.

en: Booting From the Network
fa-IR: راه‌اندازی از طریق شبکه

en: Preparing a Bootable USB Key
fa-IR: آماده‌سازی یک USB قابل اجرا

en: syslinux.cfg file and preseeding parameters
fa-IR: فایل syslinux.cfg و پارامترهای عملیات آماده‌سازی

en: Creating a CD-ROM Image
fa-IR: ایجاد یک تصویر CD-ROM

en: A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by <emphasis role="pkg">debian-cd</emphasis>, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by <filename>/usr/share/debian-cd/CONF.sh</filename>; even then, <command>make</command> must be invoked several times. <filename>/usr/share/debian-cd/README</filename> is therefore a very recommended read.
fa-IR: یک حافظه USB از نوع رسانه‌های خواندنی-نوشتنی است، پس تغییر فایل در آن و افزودن پارامترها کار آسانی است. در مورد CD-ROM، این عملیات از پیچیدگی بیشتری برخوردار است چرا که نیازمند تولید مجدد تصویر ISO از آن می‌باشد. این وظیفه توسط <emphasis role="pkg">debian-cd</emphasis> مدیریت می‌شود، اما استفاده از این ابزار برای اینکار مطلوب نیست: نیازمند یک mirror محلی و درک از گزینه‌های موجود در <filename>/usr/share/debian-cd/CONF.sh</filename> است؛ حتی در این صورت، <command>make</command> چندین بار باید فراخوانی شود. بنابراین مطالعه <filename>/usr/share/debian-cd/README</filename> به شدت توصیه می‌گردد.

en: Simple-CDD: The All-In-One Solution
fa-IR: Simple-CDD: یک راهکار جامع

en: Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.
fa-IR: استفاده از یک فایل preseed به تنهایی تمام پیشنیازهای فرآیندهای بزرگ توسعه را محقق نمی‌کند. با اینکه امکان اجرای چند اسکریپت در انتهای فرآیند نصب وجود دارد، مجموعه بسته‌هایی که باید نصب گردند به سادگی قابل دسترس نمی‌باشند (معمولا، فقط “task” می‌تواند انتخاب شود)؛ مهمتر اینکه، این روش منجر به نصب بسته‌های رسمی از دبیان می‌شود و سایر بسته‌های محلی را نادیده می‌گیرد.

en: Creating Profiles
fa-IR: ایجاد پروفایل‌ها

en: Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of <filename>profiles/<replaceable>profile</replaceable>.*</filename> files:
fa-IR: Simple-CDD “پروفایل” را تعریف می‌کند که با مفهوم “کلاس” در FAI سازگار هستند و یک ماشین می‌تواند چندین پروفایل داشته باشد (که در زمان نصب مشخص می‌شوند). یک پروفایل توسط مجموعه فایل‌های <filename>profiles/<replaceable>profile</replaceable>.*</filename> تعریف می‌شود:

en: the <filename>.description</filename> file contains a one-line description for the profile;
fa-IR: فایل <filename>.description</filename> شامل توضیح یک خطی درباره پروفایل است؛

en: the <filename>.packages</filename> file lists packages that will automatically be installed if the profile is selected;
fa-IR: فایل <filename>.packages</filename> شامل بسته‌هایی است که در صورت انتخاب شدن پروفایل به شیوه خودکار نصب می‌گردند؛

en: the <filename>.downloads</filename> file lists packages that will be stored onto the installation media, but not necessarily installed;
fa-IR: فایل <filename>.downloads</filename> شامل بسته‌هایی است که درون رسانه نصب ذخیره‌سازی می‌شوند، اما الزامی در نصب آن‌ها وجود ندارد؛

en: the <filename>.preseed</filename> file contains preseeding information for Debconf questions (for the installer and/or for packages);
fa-IR: فایل <filename>.preseed</filename> شامل اطلاعات آماده‌سازی برای پرسش‌های Debconf (برای نصب‌کننده و/یا بسته‌ها) می‌باشد؛

en: the <filename>.postinst</filename> file contains a script that will be run at the end of the installation process;
fa-IR: فایل <filename>.postinst</filename> شامل اسکریپتی است که در انتهای فرآیند نصب اجرا می‌شود؛

en: The <literal>default</literal> profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the <literal>simple-cdd/profiles</literal> preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.
fa-IR: پروفایل <literal>default</literal> نقش ویژه‌ای دارد چرا که همیشه انتخاب می‌شود؛ شامل حداقل‌های مورد نیاز توسط Simple-CDD است. تنها موردی که در این پروفایل سفارشی می‌شود پارامتر آماده‌سازی <literal>simple-cdd/profiles</literal> است: امکان رد کردن پرسش، که توسط Simple-CDD، درباره پروفایل قابل نصب را فراهم می‌کند.

en: Note also that the commands will need to be invoked from the parent directory of the <filename>profiles</filename> directory.
fa-IR: به یاد داشته باشید که دستورات باید از دایرکتوی والد <filename>profiles</filename> فراخوانی شوند.

en: Configuring and Using <command>build-simple-cdd</command>
fa-IR: پیکربندی و استفاده از <command>build-simple-cdd</command>

en: <emphasis>QUICK LOOK</emphasis> Detailed configuration file
fa-IR: <emphasis>نگاه سریع</emphasis> فایل پیکربندی همراه با جزئیات

en: Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which <command>build-simple-cdd</command> can be pointed at with the <literal>--conf</literal> option, but they can also be specified via dedicated parameters given to <command>build-simple-cdd</command>. Here is an overview of how this command behaves, and how its parameters are used:
fa-IR: Simple-CDD به پارامترهای بسیاری برای عملکرد جامع نیاز دارد. آن‌ها اغلب درون یک فایل پیکربندی قرار دارند، که <command>build-simple-cdd</command> می‌تواند با گزینه <literal>--conf</literal> به آن اشاره کند، همچنین می‌توانند با استفاده از پارامترهای انحصاری به <command>build-simple-cdd</command> ارجاع شوند. در اینجا به این دستور و پارامترهای مورد نیاز آن نگاهی می‌اندازیم:

en: the <literal>profiles</literal> parameter lists the profiles that will be included on the generated CD-ROM image;
fa-IR: پارامتر <literal>profiles</literal> فهرستی از پروفایل‌های قابل اجرا در CD-ROM ایجاد شده را فهرست می‌کند؛

en: based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in <literal>server</literal>, and gathers them into a partial mirror (which will later be given to debian-cd);
fa-IR: بر اساس فهرست بسته‌های مورد نیاز، Simple-CDD فایل‌های متناسب با آن‌ها را از سرور اشاره شده در <literal>server</literal> دانلود کرده و آن‌ها را درون یک mirror موقت قرار می‌دهد (که در ادامه به debian-cd داده می‌شود)؛

en: the custom packages mentioned in <literal>local_packages</literal> are also integrated into this local mirror;
fa-IR: بسته‌های سفارشی موجود در <literal>local_packages</literal> نیز درون همین mirror محلی قرار می‌گیرند؛

en: debian-cd is then executed (within a default location that can be configured with the <literal>debian_cd_dir</literal> variable), with the list of packages to integrate;
fa-IR: سپس debian-cd (درون یک مکان پیشفرض که می‌تواند با متغیر <literal>debian_cd_dir</literal> پیکربندی شود) همراه با فهرستی از بسته‌ها به منظور یکپارچه‌سازی اجرا می‌شود؛

en: once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:
fa-IR: زمانی که debian-cd دایرکتوری خود را آماده کند، Simple-CDD برخی تغییرات را در این دایرکتوری انجام می‌دهد:

en: files containing the profiles are added in a <filename>simple-cdd</filename> subdirectory (that will end up on the CD-ROM);
fa-IR: فایل‌هایی که شامل پروفایل‌ها هستند درون یک دایرکتوری زیر مجموعه <filename>simple-cdd</filename> (واقع در CD-ROM نهایی) قرار می‌گیرند؛

en: other files listed in the <literal>all_extras</literal> parameter are also added;
fa-IR: سایر فایل‌های فهرست شده در پارامتر <literal>all_extras</literal> نیز افزوده می‌شوند؛

en: the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the <literal>language</literal> and <literal>country</literal> variables.
fa-IR: پارامترهای راه‌اندازی طوری تنظیم می‌شوند که عملیات preseed فعال گردد. در صورت ذخیره‌سازی اطلاعات لازم در متغیرهای <literal>language</literal> و <literal>country</literal>، پرسش‌های مربوط به زبان و کشور نادیده گرفته می‌شوند.

en: debian-cd then generates the final ISO image.
fa-IR: سپس debian-cd فایل نهایی ISO را تولید می‌کند.

en: Generating an ISO Image
fa-IR: تولید یک فایل ISO

en: Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.
fa-IR: مانیتورینگ یک عبارت عمومی است و فعالیت‌های مرتبط با آن اهداف گوناگونی را دنبال می‌کنند: از یک طرف، پیگیری منابع مصرفی فراهم شده توسط ماشین امکان پیشبینی میزان اشباع و بروزرسانی‌های متعاقب با آن را فراهم می‌کند؛ از طرف دیگر، هشدار به مدیر سیستم به محض اینکه یک سرویس از دسترس خارج شود یا به درستی کار نکند به معنی رفع سریع‌تر مشکلات در زمان بروز حادثه است.

en: <emphasis>Munin</emphasis> covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). <emphasis>Nagios</emphasis> covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.
fa-IR: <emphasis>Munin</emphasis> با نمایش نمودارهای گرافیکی برای مقادیر مختلف از پارامترهای متعدد (حافظه مصرفی، فضای اشغال شده دیسک، بار پردازنده، ترافیک شبکه، بار وب سرور/پایگاه‌داده و از این قبیل) ناحیه اول را پوشش می‌دهد. <emphasis>Nagios</emphasis> با بررسی مداوم سرویس‌ها و نحوه کارکرد و قابل دسترس بودن آن‌ها، همراه با ارسال پیام به مدیر سیستم با استفاده از کانال‌های مناسب (ایمیل، پیامک و از این قبیل) ناحیه دوم را پوشش می‌دهد. هر دو ابزار ساختاری ماژولار دارند که به توسعه هر یک از آن‌ها و افزودن پارامترها یا سرویس‌های خاص کمک می‌کند.

en: <emphasis>ALTERNATIVE</emphasis> Zabbix, an integrated monitoring tool
fa-IR: <emphasis>جایگزین</emphasis> Zabbix، یک ابزار مانیتورینگ یکپارچه

en: <emphasis>ALTERNATIVE</emphasis> Icinga, a Nagios fork
fa-IR: <emphasis>جایگزین</emphasis> Icinga، یک fork از Nagios

en: Setting Up Munin
fa-IR: راه‌اندازی Munin

en: The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.
fa-IR: هدف Munin مانیتور کردن ماشین‌های متعدد است؛ بنابراین، طبیعی است که از معماری کلاینت/سرور استفاده کند. میزبان مرکزی - یا grapher - داده را از تمام میزبان‌های قابل مانیتور کردن دریافت کرده و نمودارهای گرافیکی تولید می‌کند.

en: Configuring Hosts To Monitor
fa-IR: پیکربندی میزبان‌ها برای مانیتور شدن

en: The first step is to install the <emphasis role="pkg">munin-node</emphasis> package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in <filename>/usr/share/munin/plugins/</filename>, but only those with a symbolic link in <filename>/etc/munin/plugins/</filename> are really used.
fa-IR: اولین گام نصب بسته <emphasis role="pkg">munin-node</emphasis> است. فرآیند پس‌زمینه‌ای که توسط این بسته نصب می‌شود به درگاه ۴۹۴۹ گوش کرده و داده‌های دریافتی از پلاگین‌های فعال را ارسال می‌کند. هر پلاگین یک برنامه ساده است که توضیح مرتبط با داده دریافتی همراه با آخرین مقدار بدست آمده را باز می‌گرداند. پلاگین‌ها در مسیر <filename>/usr/share/munin/plugins/</filename> ذخیره شده‌اند اما تنها آن‌هایی که به صورت پیوند نمادین در <filename>/etc/munin/plugins/</filename> قرار داشته باشند، استفاده می‌گردند.

en: <emphasis>GOING FURTHER</emphasis> Creating local plugins
fa-IR: <emphasis>مطالعه بیشتر</emphasis> ایجاد پلاگین‌های محلی

en: A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running <command>munin-run <replaceable>plugin</replaceable></command> as root. A potential second parameter given to this command (such as <literal>config</literal>) is passed to the plugin as a parameter.
fa-IR: یک پلاگین بهتر است در شرایط مشابه با فراخوانی توسط munin-node مورد آزمون قرار گیرد؛ این عمل با اجرای <command>munin-run <replaceable>plugin</replaceable></command> به عنوان root شبیه‌سازی می‌شود. یک پارامتر دوم احتمالی که به این دستور داده می‌شود (از جمله <literal>config</literal>) به عنوان یک پارامتر به پلاگین فرستاده می‌شود.

en: When a plugin is invoked with the <literal>config</literal> parameter, it must describe itself by returning a set of fields:
fa-IR: زمانی که یک پلاگین توسط پارامتر <literal>config</literal> فراخوانی می‌شود، باید خود را با بازگرداندن مجموعه‌ای از فیلدها تعریف کند:

en: When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing <command>sudo munin-run load</command> could return <literal>load.value 0.12</literal>.
fa-IR: زمانی که بدون پارامتر فراخوانی می‌شود، پلاگین به سادگی آخرین مقدار محاسبه شده را باز می‌گرداند؛ برای نمونه، اجرای <command>sudo munin-run load</command> می‌تواند مقدار <literal>load.value 0.12</literal> را باز گرداند.

en: Finally, when a plugin is invoked with the <literal>autoconf</literal> parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.
fa-IR: در نهایت، زمانی که یک پلاگین توسط پارامتر <literal>autoconf</literal> فراخوانی می‌شود، باید مقدار “yes” (گزارش خروج ۰) یا “no” (گزارش خروج ۱) با توجه به اینکه آیا پلاگین باید در این میزبان فعال شود یا خیر را باز گرداند.

en: Configuring the Grapher
fa-IR: پیکربندی Grapher

en: The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the <emphasis role="pkg">munin</emphasis> package. The standard configuration runs <command>munin-cron</command> (once every 5 minutes), which gathers data from all the hosts listed in <filename>/etc/munin/munin.conf</filename> (only the local host is listed by default), saves the historical data in RRD files (<emphasis>Round Robin Database</emphasis>, a file format designed to store data varying in time) stored under <filename>/var/lib/munin/</filename> and generates an HTML page with the graphs in <filename>/var/cache/munin/www/</filename>.
fa-IR: “grapher” در واقع رایانه‌ای است که داده‌ها را گردآوری کرده و نمودارهای مرتبط با آن را رسم می‌کند. نرم‌افزار مورد نیاز در بسته <emphasis role="pkg">munin</emphasis> قرار دارد. پیکربندی استاندارد <command>munin-cron</command> را هر ۵ دقیقه یکبار اجرا کرده، تا اطلاعات از تمام میزبان‌های موجود در <filename>/etc/munin/munin.conf</filename> گردآوری شوند (فقط میزبان محلی به صورت پیشفرض قرار دارد)، داده‌های بدست آمده را در فایل‌های RRD، که مخفف <emphasis>Round Robin Database</emphasis> و مناسب ذخیره‌سازی داده‌های متغیر در طول زمان است، ذخیره‌سازی می‌کند که این فایل‌ها در مسیر <filename>/var/lib/munin/</filename> قرار دارند و در نهایت یک صفحه HTML همراه با نمودارها در <filename>/var/cache/munin/www/</filename> ایجاد می‌کند.

en: All monitored machines must therefore be listed in the <filename>/etc/munin/munin.conf</filename> configuration file. Each machine is listed as a full section with a name matching the machine and at least an <literal>address</literal> entry giving the corresponding IP address.
fa-IR: بنابراین تمام ماشین‌های مانیتور شده باید در فایل پیکربندی <filename>/etc/munin/munin.conf</filename> قرار داشته باشند. هر ماشین به عنوان یک قسمت کامل همراه با نام آن و حداقل یک مدخل <literal>address</literal> که شامل نشانی IP ماشین است، قرار می‌گیرد.

en: Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.
fa-IR: قسمت‌ها می‌توانند پیچیده‌تر باشند، تا با ترکیب داده‌های بدست آمده از چند ماشین نمودارهای اضافی رسم گردد. مثال‌های موجود در فایل پیکربندی نقطه آغاز مناسبی برای سفارشی‌کردن این فرآیند هستند.

en: The last step is to publish the generated pages; this involves configuring a web server so that the contents of <filename>/var/cache/munin/www/</filename> are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See <xref linkend="sect.http-web-server" /> for the relevant details.
fa-IR: آخرین گام انتشار صفحات تولید شده است؛ اینکار نیازمند پیکربندی سرور وب به گونه‌ای است که محتوای <filename>/var/cache/munin/www/</filename> از طریق یک وبسایت قابل دسترس باشد. دسترسی به این وبسایت می‌تواند با استفاده از مکانیزم احرازهویت یا کنترل دسترسی مبتنی بر IP مدیریت شود. برای جزئیات مرتبط <xref linkend="sect.http-web-server" /> را مشاهده کنید.

en: Setting Up Nagios
fa-IR: راه‌اندازی Nagios

en: Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.
fa-IR: برخلاف Munin، الزامی بر نصب Nagios روی میزبان‌های مانیتور شده نیست؛ از Nagios بیشتر به منظور بررسی موجود بودن سرویس‌های شبکه استفاده می‌شود. برای نمونه، Nagios می‌تواند به یک سرور وب متصل شده و بررسی کند یک صفحه مشخص در زمان مشخص قابل دسترس است یا خیر.

en: Installing
fa-IR: نصب

en: Configuring
fa-IR: پیکربندی

en: These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:
fa-IR: بدون درک از مفاهیم Nagios نباید مستقیم سراغ این فایل‌ها رفت. پیکربندی شامل اشیایی از نوع زیر می‌باشد:

en: a <emphasis>host</emphasis> is a machine to be monitored;
fa-IR: یک <emphasis>host</emphasis> ماشینی است که باید مانیتور شود؛

en: a <emphasis>hostgroup</emphasis> is a set of hosts that should be grouped together for display, or to factor some common configuration elements;
fa-IR: یک <emphasis>hostgroup</emphasis> مجموعه‌ای از میزبان‌ها است که برای نمایش یا در نظر گرفتن برخی عناصر پیکربندی، باید گروه‌بندی شوند؛

en: a <emphasis>service</emphasis> is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);
fa-IR: یک <emphasis>service</emphasis> شامل عنصری قابل آزمون مرتبط با یک میزبان یا گروه میزبانی است. در اکثر موارد برای بررسی یک سرویس شبکه بکار می‌رود، اما می‌تواند برای بررسی محدوده مجاز برخی پارامترها نیز استفاده شود (برای نمونه، فضای آزاد دیسک یا بار پردازنده)؛

en: a <emphasis>servicegroup</emphasis> is a set of services that should be grouped together for display;
fa-IR: یک <emphasis>servicegroup</emphasis> مجموعه‌ای از سرویس‌ها است که برای نمایش باید گروه‌بندی شوند؛

en: a <emphasis>contact</emphasis> is a person who can receive alerts;
fa-IR: یک <emphasis>contact</emphasis> شخصی است که می‌تواند هشدارها را دریافت کند؛

en: a <emphasis>contactgroup</emphasis> is a set of such contacts;
fa-IR: یک <emphasis>contactgroup</emphasis> مجموعه‌ای از چنین افرادی است؛

en: a <emphasis>timeperiod</emphasis> is a range of time during which some services have to be checked;
fa-IR: یک <emphasis>timeperiod</emphasis> بازه‌ای از زمان است که طی آن برخی سرویس‌ها باید بررسی شوند؛

en: a <emphasis>command</emphasis> is the command line invoked to check a given service.
fa-IR: یک <emphasis>command</emphasis> دستوری است که به منظور بررسی یک سرویس مشخص فراخوانی می‌شود.

en: According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.
fa-IR: با توجه به نوع، هر شی شامل قابلیت‌هایی است که می‌تواند سفارشی شود. فهرست کامل آن بسیار طولانی است، اما مهم‌ترین قابلیت‌ها همان روابط بین اشیا است.

en: A <emphasis>service</emphasis> uses a <emphasis>command</emphasis> to check the state of a feature on a <emphasis>host</emphasis> (or a <emphasis>hostgroup</emphasis>) within a <emphasis>timeperiod</emphasis>. In case of a problem, Nagios sends an alert to all members of the <emphasis>contactgroup</emphasis> linked to the service. Each member is sent the alert according to the channel described in the matching <emphasis>contact</emphasis> object.
fa-IR: یک <emphasis>service</emphasis> از <emphasis>command</emphasis> استفاده می‌کند تا وضعیت یک قابلیت موجود در<emphasis>host</emphasis> (یا <emphasis>hostgroup</emphasis>) را طی بازه <emphasis>timeperiod</emphasis> بررسی کند. در صورت بروز مشکل، Nagios یک هشدار به تمام اعضای موجود در <emphasis>contactgroup</emphasis> مرتبط با سرویس ارسال می‌کند. با توجه به کانال تعریف شده برای هر فرد در شی <emphasis>contact</emphasis>، پیام برای وی فرستاده می‌شود.

en: The Falcot Corp administrators use the following configuration:
fa-IR: مدیرسیستم‌های شرکت فالکوت از پیکربندی زیر استفاده می‌کنند:

en: Note the use of inheritance: an object is made to inherit from another object with the “use <replaceable>parent-name</replaceable>”. The parent object must be identifiable, which requires giving it a “name <replaceable>identifier</replaceable>” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.
fa-IR: کاربرد ارث‌گرایی را به یاد داشته باشید: یک شی می‌تواند از شی دیگری با استفاده از “use <replaceable>parent-name</replaceable>” ارث‌بری کند. شی والد باید قابل شناسایی باشد، که نیازمند اختصاص قابلیت “name <replaceable>identifier</replaceable>” به آن می‌باشد. اگر قرار بر واقعی نبودن شی والد باشد، اما تنها به صورت والد عمل کند، اختصاص قابلیت “register 0” به آن به Nagios می‌گوید که از آن شی صرف نظر کند، که در این صورت نبود برخی پارامترهای مورد نیاز آن مشکلی را بوجود نمی‌آورد.

en: <emphasis>DOCUMENTATION</emphasis> List of object properties
fa-IR: <emphasis>مستندات</emphasis> فهرستی از قابلیت‌های شی

en: <emphasis>GOING FURTHER</emphasis> Remote tests with NRPE
fa-IR: <emphasis>مطالعه بیشتر</emphasis> آزمون‌های راه‌دور با استفاده از NRPE
