Bug 1695262

Summary:	[DOCS] - Installation Guide Expand LVM simple bluestore scenario to include additional HDD's & nvmes
Product:	[Red Hat Storage] Red Hat Ceph Storage	Reporter:	mamccoma
Component:	Documentation	Assignee:	Ranjini M N <rmandyam>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ameena Suhani S H <amsyedha>
Severity:	high	Docs Contact:	Aron Gunn <agunn>
Priority:	high
Version:	3.2	CC:	agunn, amsyedha, assingh, bubrown, dhill, fiezzi, gjose, gsitlani, hyelloji, johfulto, kdreyer, lmarsh, mamccoma, mhackett, mmuench, nyewale, rmandyam, shtiwari, vumrao
Target Milestone:	rc
Target Release:	4.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	RHCS 4.1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-06-04 10:27:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1809603

Description mamccoma 2019-04-02 18:14:26 UTC

Hello,

In the Installation document, under "LVM simple" we illustrate the following for this second scenario:

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/installation_guide_for_red_hat_enterprise_linux/#installing-a-red-hat-ceph-storage-cluster



osd_objectstore: bluestore
osd_scenario: lvm
devices:
  - /dev/sda
  - /dev/sdb
  - /dev/nvme0n1

In the second scenario, when there is a mix of traditional hard drives and SSDs, the data is placed on the traditional hard drives (sda, sdb) and the BlueStore database (block.db) is created as large as possible on the SSD (nvme0n1).


However, recently it was identified that you can use this same concept to apply to separating HDDs and making use of more then one nvme. Having said, this I am proposing something along the lines of the following as an idea:
================================================================================

"osd_objectstore: bluestore
osd_scenario: lvm
devices:
  - /dev/sda
  - /dev/sdb
  - /dev/nvme0n1
  - /dev/sdc
  - /dev/sdd
  - /dev/nvme1n1

In the second scenario, when there is a mix of traditional hard drives and SSDs, the data is placed on the traditional hard drives (sda, sdb) and the BlueStore database (block.db) is created as large as possible on the SSD (nvme0n1). Additionally, traditional hard drives (sdc,sdd) will receive the data while nvme1n1 will respectively receive the block.db for these two respective disks."



- Please let me know if you have any additional questions on this.

Thanks!

Comment 1 John Fulton 2019-07-24 19:56:22 UTC

When this docbug is implemented there should be a warning which captures the following idea:

Be careful when using the proposed syntax to not run into bug 1732915. You can do the following and get the desired results:

devices:
 - slow
 - slow
 - slow
 - slow
 - fast
 - slow
 - slow
 - slow
 - slow
 - fast

bug ONLY if the slow devices are HDDs and the fast devices are SSDs. 

If the slow devices are SSDs and the fast devices are NVMe SSDs, then the above won't work because all of the devices will look like SSDs and then you'll get 10 OSDs where two of them are faster instead of 8 OSDs with a fast bluestore DB device.

If you want to deploy in that scenario, then you need to directly create the LVMs in advance as described in https://access.redhat.com/solutions/3954161

Comment 2 John Fulton 2019-07-24 19:57:23 UTC

(In reply to John Fulton from comment #1)
> When this docbug is implemented there should be a warning which captures the
> following idea:
> 
> Be careful when using the proposed syntax to not run into bug 1732915. You
> can do the following and get the desired results:
> 
> devices:
>  - slow
>  - slow
>  - slow
>  - slow
>  - fast
>  - slow
>  - slow
>  - slow
>  - slow
>  - fast
> 
> bug ONLY if the slow devices are HDDs and the fast devices are SSDs. 

I meant to say _but_ only if....

Comment 3 John Fulton 2019-07-24 20:19:55 UTC

*** Bug 1732915 has been marked as a duplicate of this bug. ***

Comment 4 Giridhar Ramaraju 2019-08-05 13:10:11 UTC

Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. 

Regards,
Giri

Comment 5 Giridhar Ramaraju 2019-08-05 13:11:17 UTC

Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. 

Regards,
Giri