CPU
===
-Ceph metadata servers dynamically redistribute their load, which is CPU
-intensive. So your metadata servers should have significant processing power
-(e.g., quad core or better CPUs). Ceph OSDs run the :term:`RADOS` service, calculate
+CephFS metadata servers are CPU intensive, so they should have significant
+processing power (e.g., quad core or better CPUs) and benefit from higher clock
+rate (frequency in GHz). Ceph OSDs run the :term:`RADOS` service, calculate
data placement with :term:`CRUSH`, replicate data, and maintain their own copy of the
-cluster map. Therefore, OSDs should have a reasonable amount of processing power
-(e.g., dual core processors). Monitors simply maintain a master copy of the
-cluster map, so they are not CPU intensive. You must also consider whether the
+cluster map. Therefore, OSD nodes should have a reasonable amount of processing
+power. Requirements vary by use-case; a starting point might be one core per
+OSD for light / archival usage, and two cores per OSD for heavy workloads such
+as RBD volumes attached to VMs. Monitor / manager nodes do not have heavy CPU
+demands so a modest processor can be chosen for them. Also consider whether the
host machine will run CPU-intensive processes in addition to Ceph daemons. For
example, if your hosts will run computing VMs (e.g., OpenStack Nova), you will
need to ensure that these other processes leave sufficient processing power for
Ceph daemons. We recommend running additional CPU-intensive processes on
-separate hosts.
+separate hosts to avoid resource contention.
RAM
===
-Generally, more RAM is better.
+Generally, more RAM is better. Monitor / manager nodes for a modest cluster
+might do fine with 64GB; for a larger cluster with hundreds of OSDs 128GB
+is a reasonable target. There is a memory target for BlueStore OSDs that
+defaults to 4GB. Factor in a prudent margin for the operating system and
+administrative tasks (like monitoring and metrics) as well as increased
+consumption during recovery: provisioning ~8GB per BlueStore OSD
+is advised.
Monitors and managers (ceph-mon and ceph-mgr)
---------------------------------------------
Monitor and manager daemon memory usage generally scales with the size of the
-cluster. For small clusters, 1-2 GB is generally sufficient. For
-large clusters, you should provide more (5-10 GB). You may also want
-to consider tuning settings like ``mon_osd_cache_size`` or
-``rocksdb_cache_size``.
+cluster. Note that at boot-time and during topology changes and recovery these
+daemons will need more RAM than they do during steady-state operation, so plan
+for peak usage. For very small clusters, 32 GB suffices. For
+clusters of up to, say, 300 OSDs go with 64GB. For clusters built with (or
+which will grow to) even more OSDS you should provision
+128GB. You may also want to consider tuning settings like ``mon_osd_cache_size``
+or ``rocksdb_cache_size`` after careful research.
Metadata servers (ceph-mds)
---------------------------
configured to consume. We recommend 1 GB as a minimum for most systems. See
``mds_cache_memory``.
-OSDs (ceph-osd)
----------------
-By default, OSDs that use the BlueStore backend require 3-5 GB of RAM. You can
-adjust the amount of memory the OSD consumes with the ``osd_memory_target`` configuration option when BlueStore is in use. When using the legacy FileStore backend, the operating system page cache is used for caching data, so no tuning is normally needed, and the OSD memory consumption is generally related to the number of PGs per daemon in the system.
+Memory
+======
+
+Bluestore uses its own memory to cache data rather than relying on the
+operating system page cache. In bluestore you can adjust the amount of memory
+the OSD attempts to consume with the ``osd_memory_target`` configuration
+option.
+
+- Setting the osd_memory_target below 2GB is typically not recommended (it may
+ fail to keep the memory that low and may also cause extremely slow performance.
+
+- Setting the memory target between 2GB and 4GB typically works but may result
+ in degraded performance as metadata may be read from disk during IO unless the
+ active data set is relatively small.
+
+- 4GB is the current default osd_memory_target size and was set that way to try
+ and balance memory requirements and OSD performance for typical use cases.
+
+- Setting the osd_memory_target higher than 4GB may improve performance when
+ there are many (small) objects or large (256GB/OSD or more) data sets being
+ processed.
+
+.. important:: The OSD memory autotuning is "best effort". While the OSD may
+ unmap memory to allow the kernel to reclaim it, there is no guarantee that
+ the kernel will actually reclaim freed memory within any specific time
+ frame. This is especially true in older versions of Ceph where transparent
+ huge pages can prevent the kernel from reclaiming memory freed from
+ fragmented huge pages. Modern versions of Ceph disable transparent huge
+ pages at the application level to avoid this, though that still does not
+ guarantee that the kernel will immediately reclaim unmapped memory. The OSD
+ may still at times exceed it's memory target. We recommend budgeting around
+ 20% extra memory on your system to prevent OSDs from going OOM during
+ temporary spikes or due to any delay in reclaiming freed pages by the
+ kernel. That value may be more or less than needed depending on the exact
+ configuration of the system.
+
+When using the legacy FileStore backend, the page cache is used for caching
+data, so no tuning is normally needed, and the OSD memory consumption is
+generally related to the number of PGs per daemon in the system.
Data Storage
OS operations, and simultaneous request for read and write operations from
multiple daemons against a single drive can slow performance considerably.
-.. important:: Since Ceph has to write all data to the journal before it can
- send an ACK (for XFS at least), having the journal and OSD
- performance in balance is really important!
-
-
Hard Disk Drives
----------------
at $150.00 has a cost of $0.05 per gigabyte (i.e., $150 / 3072 = 0.0488). In the
foregoing example, using the 1 terabyte disks would generally increase the cost
per gigabyte by 40%--rendering your cluster substantially less cost efficient.
-Also, the larger the storage drive capacity, the more memory per Ceph OSD Daemon
-you will need, especially during rebalancing, backfilling and recovery. A
-general rule of thumb is ~1GB of RAM for 1TB of storage space.
-.. tip:: Running multiple OSDs on a single disk--irrespective of partitions--is
- **NOT** a good idea.
+.. tip:: Running multiple OSDs on a single SAS / SATA drive
+ is **NOT** a good idea. NVMe drives, however, can achieve
+ improved performance by being split into two or more OSDs.
.. tip:: Running an OSD and a monitor or a metadata server on a single
- disk--irrespective of partitions--is **NOT** a good idea either.
+ drive is also **NOT** a good idea.
Storage drives are subject to limitations on seek time, access time, read and
write times, as well as total throughput. These physical limitations affect
overall system performance--especially during recovery. We recommend using a
-dedicated drive for the operating system and software, and one drive for each
-Ceph OSD Daemon you run on the host. Most "slow OSD" issues arise due to running
-an operating system, multiple OSDs, and/or multiple journals on the same drive.
-Since the cost of troubleshooting performance issues on a small cluster likely
-exceeds the cost of the extra disk drives, you can accelerate your cluster
-design planning by avoiding the temptation to overtax the OSD storage drives.
-
-You may run multiple Ceph OSD Daemons per hard disk drive, but this will likely
-lead to resource contention and diminish the overall throughput. You may store a
-journal and object data on the same drive, but this may increase the time it
-takes to journal a write and ACK to the client. Ceph must write to the journal
-before it can ACK the write.
-
-Ceph best practices dictate that you should run operating systems, OSD data and
-OSD journals on separate drives.
+dedicated (ideally mirrored) drive for the operating system and software, and
+one drive for each Ceph OSD Daemon you run on the host (modulo NVMe above).
+Many "slow OSD" issues not attributable to hardware failure arise from running
+an operating system and multiple OSDs on the same drive. Since the cost of troubleshooting performance issues on a small cluster likely exceeds the cost of the extra disk drives, you can optimize your cluster design planning by avoiding the temptation to overtax the OSD storage drives.
+You may run multiple Ceph OSD Daemons per SAS / SATA drive, but this will likely
+lead to resource contention and diminish the overall throughput.
Solid State Drives
------------------
SSDs do not have moving mechanical parts so they are not necessarily subject to
the same types of limitations as hard disk drives. SSDs do have significant
limitations though. When evaluating SSDs, it is important to consider the
-performance of sequential reads and writes. An SSD that has 400MB/s sequential
-write throughput may have much better performance than an SSD with 120MB/s of
-sequential write throughput when storing multiple journals for multiple OSDs.
+performance of sequential reads and writes.
.. important:: We recommend exploring the use of SSDs to improve performance.
However, before making a significant investment in SSDs, we **strongly
recommend** both reviewing the performance metrics of an SSD and testing the
SSD in a test configuration to gauge performance.
-Since SSDs have no moving mechanical parts, it makes sense to use them in the
-areas of Ceph that do not use a lot of storage space (e.g., journals).
Relatively inexpensive SSDs may appeal to your sense of economy. Use caution.
-Acceptable IOPS are not enough when selecting an SSD for use with Ceph. There
-are a few important performance considerations for journals and SSDs:
-
-- **Write-intensive semantics:** Journaling involves write-intensive semantics,
- so you should ensure that the SSD you choose to deploy will perform equal to
- or better than a hard disk drive when writing data. Inexpensive SSDs may
- introduce write latency even as they accelerate access time, because
- sometimes high performance hard drives can write as fast or faster than
- some of the more economical SSDs available on the market!
-
-- **Sequential Writes:** When you store multiple journals on an SSD you must
- consider the sequential write limitations of the SSD too, since they may be
- handling requests to write to multiple OSD journals simultaneously.
-
-- **Partition Alignment:** A common problem with SSD performance is that
- people like to partition drives as a best practice, but they often overlook
- proper partition alignment with SSDs, which can cause SSDs to transfer data
- much more slowly. Ensure that SSD partitions are properly aligned.
-
-While SSDs are cost prohibitive for object storage, OSDs may see a significant
-performance improvement by storing an OSD's journal on an SSD and the OSD's
-object data on a separate hard disk drive. The ``osd journal`` configuration
-setting defaults to ``/var/lib/ceph/osd/$cluster-$id/journal``. You can mount
-this path to an SSD or to an SSD partition so that it is not merely a file on
-the same disk as the object data.
-
-One way Ceph accelerates CephFS filesystem performance is to segregate the
+Acceptable IOPS are not enough when selecting an SSD for use with Ceph.
+
+SSDs have historically been cost prohibitive for object storage, though
+emerging QLC drives are closing the gap. HDD OSDs may see a significant
+performance improvement by offloading WAL+DB onto an SSD.
+
+One way Ceph accelerates CephFS file system performance is to segregate the
storage of CephFS metadata from the storage of the CephFS file contents. Ceph
provides a default ``metadata`` pool for CephFS metadata. You will never have to
create a pool for CephFS metadata, but you can create a CRUSH map hierarchy for
your CephFS metadata pool that points only to a host's SSD storage media. See
-`Mapping Pools to Different Types of OSDs`_ for details.
+:ref:`CRUSH Device Class<crush-map-device-class>` for details.
Controllers
-----------
-Disk controllers also have a significant impact on write throughput. Carefully,
-consider your selection of disk controllers to ensure that they do not create
-a performance bottleneck.
+Disk controllers (HBAs) can have a significant impact on write throughput.
+Carefully consider your selection to ensure that they do not create
+a performance bottleneck. Notably RAID-mode (IR) HBAs may exhibit higher
+latency than simpler "JBOD" (IT) mode HBAs, and the RAID SoC, write cache,
+and battery backup can substantially increase hardware and maintenance
+costs. Some RAID HBAs can be configured with an IT-mode "personality".
.. tip:: The `Ceph blog`_ is often an excellent source of information on Ceph
performance issues. See `Ceph Write Throughput 1`_ and `Ceph Write
Throughput 2`_ for additional details.
+Benchmarking
+------------
+
+BlueStore opens block devices in O_DIRECT and uses fsync frequently to ensure
+that data is safely persisted to media. You can evaluate a drive's low-level
+write performance using ``fio``. For example, 4kB random write performance is
+measured as follows:
+
+.. code-block:: console
+
+ # fio --name=/dev/sdX --ioengine=libaio --direct=1 --fsync=1 --readwrite=randwrite --blocksize=4k --runtime=300
+
+Write Caches
+------------
+
+Enterprise SSDs and HDDs normally include power loss protection features which
+use multi-level caches to speed up direct or synchronous writes. These devices
+can be toggled between two caching modes -- a volatile cache flushed to
+persistent media with fsync, or a non-volatile cache written synchronously.
+
+These two modes are selected by either "enabling" or "disabling" the write
+(volatile) cache. When the volatile cache is enabled, Linux uses a device in
+"write back" mode, and when disabled, it uses "write through".
+
+The default configuration (normally caching enabled) may not be optimal, and
+OSD performance may be dramatically increased in terms of increased IOPS and
+decreased commit_latency by disabling the write cache.
+
+Users are therefore encouraged to benchmark their devices with ``fio`` as
+described earlier and persist the optimal cache configuration for their
+devices.
+
+The cache configuration can be queried with ``hdparm``, ``sdparm``,
+``smartctl`` or by reading the values in ``/sys/class/scsi_disk/*/cache_type``,
+for example:
+
+.. code-block:: console
+
+ # hdparm -W /dev/sda
+
+ /dev/sda:
+ write-caching = 1 (on)
+
+ # sdparm --get WCE /dev/sda
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ WCE 1 [cha: y]
+ # smartctl -g wcache /dev/sda
+ smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)
+ Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
+
+ Write cache is: Enabled
+
+ # cat /sys/class/scsi_disk/0\:0\:0\:0/cache_type
+ write back
+
+The write cache can be disabled with those same tools:
+
+.. code-block:: console
+
+ # hdparm -W0 /dev/sda
+
+ /dev/sda:
+ setting drive write-caching to 0 (off)
+ write-caching = 0 (off)
+
+ # sdparm --clear WCE /dev/sda
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ # smartctl -s wcache,off /dev/sda
+ smartctl 7.1 2020-04-05 r5049 [x86_64-linux-4.18.0-305.19.1.el8_4.x86_64] (local build)
+ Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
+
+ === START OF ENABLE/DISABLE COMMANDS SECTION ===
+ Write cache disabled
+
+Normally, disabling the cache using ``hdparm``, ``sdparm``, or ``smartctl``
+results in the cache_type changing automatically to "write through". If this is
+not the case, you can try setting it directly as follows. (Users should note
+that setting cache_type also correctly persists the caching mode of the device
+until the next reboot):
+
+.. code-block:: console
+
+ # echo "write through" > /sys/class/scsi_disk/0\:0\:0\:0/cache_type
+
+ # hdparm -W /dev/sda
+
+ /dev/sda:
+ write-caching = 0 (off)
+
+.. tip:: This udev rule (tested on CentOS 8) will set all SATA/SAS device cache_types to "write
+ through":
+
+ .. code-block:: console
+
+ # cat /etc/udev/rules.d/99-ceph-write-through.rules
+ ACTION=="add", SUBSYSTEM=="scsi_disk", ATTR{cache_type}:="write through"
+
+.. tip:: This udev rule (tested on CentOS 7) will set all SATA/SAS device cache_types to "write
+ through":
+
+ .. code-block:: console
+
+ # cat /etc/udev/rules.d/99-ceph-write-through-el7.rules
+ ACTION=="add", SUBSYSTEM=="scsi_disk", RUN+="/bin/sh -c 'echo write through > /sys/class/scsi_disk/$kernel/cache_type'"
+
+.. tip:: The ``sdparm`` utility can be used to view/change the volatile write
+ cache on several devices at once:
+
+ .. code-block:: console
+
+ # sdparm --get WCE /dev/sd*
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ WCE 0 [cha: y]
+ /dev/sdb: ATA TOSHIBA MG07ACA1 0101
+ WCE 0 [cha: y]
+ # sdparm --clear WCE /dev/sd*
+ /dev/sda: ATA TOSHIBA MG07ACA1 0101
+ /dev/sdb: ATA TOSHIBA MG07ACA1 0101
+
Additional Considerations
-------------------------
-You may run multiple OSDs per host, but you should ensure that the sum of the
-total throughput of your OSD hard disks doesn't exceed the network bandwidth
+You typically will run multiple OSDs per host, but you should ensure that the
+aggregate throughput of your OSD drives doesn't exceed the network bandwidth
required to service a client's need to read or write data. You should also
consider what percentage of the overall data the cluster stores on each host. If
the percentage on a particular host is large and the host fails, it can lead to
``syncfs(2)`` to ensure that your hardware performs as expected when running
multiple OSDs per host.
-Hosts with high numbers of OSDs (e.g., > 20) may spawn a lot of threads,
-especially during recovery and rebalancing. Many Linux kernels default to
-a relatively small maximum number of threads (e.g., 32k). If you encounter
-problems starting up OSDs on hosts with a high number of OSDs, consider
-setting ``kernel.pid_max`` to a higher number of threads. The theoretical
-maximum is 4,194,303 threads. For example, you could add the following to
-the ``/etc/sysctl.conf`` file::
-
- kernel.pid_max = 4194303
-
Networks
========
-We recommend that each host have at least two 1Gbps network interface
-controllers (NICs). Since most commodity hard disk drives have a throughput of
-approximately 100MB/second, your NICs should be able to handle the traffic for
-the OSD disks on your host. We recommend a minimum of two NICs to account for a
-public (front-side) network and a cluster (back-side) network. A cluster network
-(preferably not connected to the internet) handles the additional load for data
-replication and helps stop denial of service attacks that prevent the cluster
-from achieving ``active + clean`` states for placement groups as OSDs replicate
-data across the cluster. Consider starting with a 10Gbps network in your racks.
-Replicating 1TB of data across a 1Gbps network takes 3 hours, and 3TBs (a
-typical drive configuration) takes 9 hours. By contrast, with a 10Gbps network,
-the replication times would be 20 minutes and 1 hour respectively. In a
-petabyte-scale cluster, failure of an OSD disk should be an expectation, not an
-exception. System administrators will appreciate PGs recovering from a
-``degraded`` state to an ``active + clean`` state as rapidly as possible, with
-price / performance tradeoffs taken into consideration. Additionally, some
-deployment tools (e.g., Dell's Crowbar) deploy with five different networks,
-but employ VLANs to make hardware and network cabling more manageable. VLANs
-using 802.1q protocol require VLAN-capable NICs and Switches. The added hardware
-expense may be offset by the operational cost savings for network setup and
-maintenance. When using VLANs to handle VM traffic between the cluster
-and compute stacks (e.g., OpenStack, CloudStack, etc.), it is also worth
-considering using 10G Ethernet. Top-of-rack routers for each network also need
-to be able to communicate with spine routers that have even faster
-throughput--e.g., 40Gbps to 100Gbps.
+Provision at least 10Gbps+ networking in your racks. Replicating 1TB of data
+across a 1Gbps network takes 3 hours, and 10TBs takes 30 hours! By contrast,
+with a 10Gbps network, the replication times would be 20 minutes and 1 hour
+respectively. In a petabyte-scale cluster, failure of an OSD drive is an
+expectation, not an exception. System administrators will appreciate PGs
+recovering from a ``degraded`` state to an ``active + clean`` state as rapidly
+as possible, with price / performance tradeoffs taken into consideration.
+Additionally, some deployment tools employ VLANs to make hardware and network
+cabling more manageable. VLANs using 802.1q protocol require VLAN-capable NICs
+and Switches. The added hardware expense may be offset by the operational cost
+savings for network setup and maintenance. When using VLANs to handle VM
+traffic between the cluster and compute stacks (e.g., OpenStack, CloudStack,
+etc.), there is additional value in using 10G Ethernet or better; 40Gb or
+25/50/100 Gb networking as of 2020 is common for production clusters.
+
+Top-of-rack routers for each network also need to be able to communicate with
+spine routers that have even faster throughput, often 40Gbp/s or more.
+
Your server hardware should have a Baseboard Management Controller (BMC).
-Administration and deployment tools may also use BMCs extensively, so consider
+Administration and deployment tools may also use BMCs extensively, especially
+via IPMI or Redfish, so consider
the cost/benefit tradeoff of an out-of-band network for administration.
Hypervisor SSH access, VM image uploads, OS image installs, management sockets,
etc. can impose significant loads on a network. Running three networks may seem
===============
A failure domain is any failure that prevents access to one or more OSDs. That
-could be a stopped daemon on a host; a hard disk failure, an OS crash, a
+could be a stopped daemon on a host; a hard disk failure, an OS crash, a
malfunctioning NIC, a failed power supply, a network outage, a power outage, and
so forth. When planning out your hardware needs, you must balance the
temptation to reduce costs by placing too many responsibilities into too few
+--------------+----------------+-----------------------------------------+
| Process | Criteria | Minimum Recommended |
+==============+================+=========================================+
-| ``ceph-osd`` | Processor | - 1x 64-bit AMD-64 |
-| | | - 1x 32-bit ARM dual-core or better |
+| ``ceph-osd`` | Processor | - 1 core minimum |
+| | | - 1 core per 200-500 MB/s |
+| | | - 1 core per 1000-3000 IOPS |
+| | | |
+| | | * Results are before replication. |
+| | | * Results may vary with different |
+| | | CPU models and Ceph features. |
+| | | (erasure coding, compression, etc) |
+| | | * ARM processors specifically may |
+| | | require additional cores. |
+| | | * Actual performance depends on many |
+| | | factors including drives, net, and |
+| | | client throughput and latency. |
+| | | Benchmarking is highly recommended. |
| +----------------+-----------------------------------------+
-| | RAM | ~1GB for 1TB of storage per daemon |
+| | RAM | - 4GB+ per daemon (more is better) |
+| | | - 2-4GB often functions (may be slow) |
+| | | - Less than 2GB not recommended |
| +----------------+-----------------------------------------+
| | Volume Storage | 1x storage drive per daemon |
| +----------------+-----------------------------------------+
-| | Journal | 1x SSD partition per daemon (optional) |
+| | DB/WAL | 1x SSD partition per daemon (optional) |
| +----------------+-----------------------------------------+
-| | Network | 2x 1GB Ethernet NICs |
+| | Network | 1x 1GbE+ NICs (10GbE+ recommended) |
+--------------+----------------+-----------------------------------------+
-| ``ceph-mon`` | Processor | - 1x 64-bit AMD-64 |
-| | | - 1x 32-bit ARM dual-core or better |
+| ``ceph-mon`` | Processor | - 2 cores minimum |
| +----------------+-----------------------------------------+
-| | RAM | 1 GB per daemon |
+| | RAM | 2-4GB+ per daemon |
| +----------------+-----------------------------------------+
-| | Disk Space | 10 GB per daemon |
+| | Disk Space | 60 GB per daemon |
| +----------------+-----------------------------------------+
-| | Network | 2x 1GB Ethernet NICs |
+| | Network | 1x 1GbE+ NICs |
+--------------+----------------+-----------------------------------------+
-| ``ceph-mds`` | Processor | - 1x 64-bit AMD-64 quad-core |
-| | | - 1x 32-bit ARM quad-core |
+| ``ceph-mds`` | Processor | - 2 cores minimum |
| +----------------+-----------------------------------------+
-| | RAM | 1 GB minimum per daemon |
+| | RAM | 2GB+ per daemon |
| +----------------+-----------------------------------------+
| | Disk Space | 1 MB per daemon |
| +----------------+-----------------------------------------+
-| | Network | 2x 1GB Ethernet NICs |
+| | Network | 1x 1GbE+ NICs |
+--------------+----------------+-----------------------------------------+
.. tip:: If you are running an OSD with a single disk, create a
OS and the volume storage.
-Production Cluster Examples
-===========================
-
-Production clusters for petabyte scale data storage may also use commodity
-hardware, but should have considerably more memory, processing power and data
-storage to account for heavy traffic loads.
-
-Dell Example
-------------
-
-A recent (2012) Ceph cluster project is using two fairly robust hardware
-configurations for Ceph OSDs, and a lighter configuration for monitors.
-
-+----------------+----------------+------------------------------------+
-| Configuration | Criteria | Minimum Recommended |
-+================+================+====================================+
-| Dell PE R510 | Processor | 2x 64-bit quad-core Xeon CPUs |
-| +----------------+------------------------------------+
-| | RAM | 16 GB |
-| +----------------+------------------------------------+
-| | Volume Storage | 8x 2TB drives. 1 OS, 7 Storage |
-| +----------------+------------------------------------+
-| | Client Network | 2x 1GB Ethernet NICs |
-| +----------------+------------------------------------+
-| | OSD Network | 2x 1GB Ethernet NICs |
-| +----------------+------------------------------------+
-| | Mgmt. Network | 2x 1GB Ethernet NICs |
-+----------------+----------------+------------------------------------+
-| Dell PE R515 | Processor | 1x hex-core Opteron CPU |
-| +----------------+------------------------------------+
-| | RAM | 16 GB |
-| +----------------+------------------------------------+
-| | Volume Storage | 12x 3TB drives. Storage |
-| +----------------+------------------------------------+
-| | OS Storage | 1x 500GB drive. Operating System. |
-| +----------------+------------------------------------+
-| | Client Network | 2x 1GB Ethernet NICs |
-| +----------------+------------------------------------+
-| | OSD Network | 2x 1GB Ethernet NICs |
-| +----------------+------------------------------------+
-| | Mgmt. Network | 2x 1GB Ethernet NICs |
-+----------------+----------------+------------------------------------+
-
projects / ceph.git / blobdiff