IBM Spectrum Scale - Revision history

Patrick at 08:39, 5 June 2018

2018-06-05T08:39:11Z

Patrick at 08:37, 5 June 2018

2018-06-05T08:37:10Z

Patrick at 08:36, 5 June 2018

2018-06-05T08:36:28Z

Patrick at 08:35, 5 June 2018

2018-06-05T08:35:47Z

Patrick at 10:08, 11 April 2018

2018-04-11T10:08:19Z

David: /* GPFS Cluster Configuration */

2018-03-21T16:25:46Z

GPFS Cluster Configuration

Mohammed at 17:04, 14 March 2018

2018-03-14T17:04:37Z

Mohammed: /* GPFS Cluster Configuration */

2018-03-14T17:03:56Z

GPFS Cluster Configuration

Mohammed: /* GPFS Cluster Configuration */

2018-03-14T16:53:49Z

GPFS Cluster Configuration

Mohammed: /* Server Configuration */

2018-03-14T16:52:05Z

Server Configuration

Show changes

← Older revision		Revision as of 08:39, 5 June 2018
Line 162:		Line 162:
	[[ Installation ]]		[[ Installation ]]

−	[[ NVMesh ~~\|GPFS_NVMesh~~]]	+	[[ GPFS_NVMesh \| NVMesh ]]

← Older revision		Revision as of 08:37, 5 June 2018
Line 162:		Line 162:
	[[ Installation ]]		[[ Installation ]]

−	[[ NVMesh ]]	+	[[ NVMesh \|GPFS_NVMesh]]

@@ Line 159: / Line 159: @@
 # No policy is validated but not activated
-### Installation
 [[ Installation ]]
 [[ NVMesh ]]

← Older revision		Revision as of 08:35, 5 June 2018
Line 161:		Line 161:
	### Installation		### Installation
	[[ Installation ]]		[[ Installation ]]
		+
		+	###
		+	[[ NVMesh ]]

← Older revision		Revision as of 10:08, 11 April 2018
Line 158:		Line 158:
	# Yes policy is validated and immediately activated		# Yes policy is validated and immediately activated
	# No policy is validated but not activated		# No policy is validated but not activated
		+
		+	### Installation
		+	[[ Installation ]]

@@ Line 130: / Line 130: @@
 Next, Create the file system using the following command
-<syntaxhighlight>mmcrfs gpfs -F stanza.nsd -j cluster -A no -B 1m -M 1 -m 1 -R 1 -r 1 -n 4 -T /scratch --metadata-block-size 128k</syntaxhighlight>
+<syntaxhighlight>mmcrfs gpfs-fsname -F stanza.nsd -j cluster -A no -B 1m -M 1 -m 1 -R 1 -r 1 -n 4 -T /scratch --metadata-block-size 128k</syntaxhighlight>
 where
 * -j Specifies the default block allocation map type
@@ Line 145: / Line 145: @@
 Next, mount the file system using
-<syntaxhighlight>mmmount file_system
+<syntaxhighlight>mmmount gpfs-fsname
 # to unmount the file system
-mmumount file_system</syntaxhighlight>
+mmumount gpfs-fsname</syntaxhighlight>
 Next, create a policy file and change the policy so that the storage for data is allocated from a different pool, hence NSDs, than for the metadata
 <syntaxhighlight>cat gpfs.policy
-RULE ‘default’ SET POOL ‘data’
+RULE ‘default’ SET POOL ‘dataPool’
-mmchpolicy scratch gpfs.policy  -I yes
+mmchpolicy gpfs-fsname gpfs.policy  -I yes
 </syntaxhighlight>
 where

← Older revision		Revision as of 17:04, 14 March 2018
Line 158:		Line 158:
	# Yes policy is validated and immediately activated		# Yes policy is validated and immediately activated
	# No policy is validated but not activated		# No policy is validated but not activated
−
−	~~=Volume Management=~~
−
−	~~By default Quobyte creates one volume configuration called BASE, which~~
−
−	~~===Viewing Volume Configurations===~~
−
−	~~Configurations can be viewed through the API or from the web console.~~
−
−	* API
−
−	~~<syntaxhighlight>~~
−	~~[root@q01 ~]# qmgmt volume config export BASE~~
−	~~configuration_name: "BASE"~~
−	~~volume_metadata_configuration {~~
−	~~placement_settings {~~
−	~~required_device_tags {~~
−	}
−	~~forbidden_device_tags {~~
−	}
−	~~prefer_client_local_device: false~~
−	~~optimize_for_mapreduce: false~~
−	}
−	~~replication_factor: 1~~
−	}
−
−	~~default_config {~~
−	~~file_layout {~~
−	~~stripe_width: 1~~
−	~~replication_factor: 1~~
−	~~block_size_bytes: 524288~~
−	~~object_size_bytes: 8388608~~
−	~~segment_size_bytes: 10737418240~~
−	~~crc_method: CRC_32_ISCSI~~
−	}
−	~~placement {~~
−	~~required_device_tags {~~
−	}
−	~~forbidden_device_tags {~~
−	}
−	~~prefer_client_local_device: false~~
−	~~optimize_for_mapreduce: false~~
−	}
−	~~io_policy {~~
−	~~cache_size_in_objects: 10~~
−	~~enable_async_writebacks: true~~
−	~~enable_client_checksum_verification: true~~
−	~~enable_client_checksum_computation: true~~
−	~~sync_writes: AS_REQUESTED~~
−	~~direct_io: AS_REQUESTED~~
−	~~OBSOLETE_implicit_locking: false~~
−	~~lost_lock_behavior: IO_ERROR~~
−	~~OBSOLETE_keep_page_cache: false~~
−	~~implicit_locking_mode: NO_LOCKING~~
−	~~enable_direct_writebacks: false~~
−	~~notify_dataservice_on_close: false~~
−	~~keep_page_cache_mode: USE_HEURISTIC~~
−	~~rpc_retry_mode: RETRY_FOREVER~~
−	~~lock_scope: GLOBAL~~
−	}
−	}
−	~~snapshot_configuration {~~
−	~~snapshot_interval_s: 0~~
−	~~snapshot_lifetime_s: 0~~
−	}
−	~~metadata_cache_configuration {~~
−	~~cache_ttl_ms: 10000~~
−	~~negative_cache_ttl_ms: 10000~~
−	~~enable_write_back_cache: false~~
−	}
−	~~</syntaxhighlight>~~
−
−
−	* Web console
−
−	~~Login to web console and navigate to "Volume Configuration". Select BASE to view the configuration.~~
−
−	~~[[File:Quobyte base vol config webconsole.png\|551px]]~~
−
−	~~===Editing Volume Configuration===~~
−
−	* API
−
−	~~<syntaxhighlight>~~
−	~~qmgmt volume config edit BASE~~
−	~~</syntaxhighlight>~~
−
−	~~This will open in your default editor (or use the value of the EDITOR environment variable if it is set).~~
−
−	* Web console
−
−	~~Navigate to 'Volume Configurations' and tick the box beside BASE. Then select 'edit' from the drop down menu.~~
−
−	~~[[file:quobyte_edit_base_config.png\|551px]]~~
−
−	~~===Creating Volume Configurations===~~
−
−	* API
−
−	To create a new config use the same command you would to edit a command, but use a configuration name that doesn't exist. For example to create a new configuration called 3x_replication run the following
−
−	~~<syntaxhighlight>~~
−	~~qmgmt volume config edit 3x_replication~~
−	~~</syntaxhighlight>~~
−
−	~~This will open an empty file in a text editor.~~
−
−	To avoid specifying every setting manually, it is advisable to inherit a different configuration to use as a template. For example to use the BASE configuration as a template for the 3x_replication add the following
−
−	~~<syntaxhighlight>~~
−	~~base_configuration: "BASE"~~
−	~~</syntaxhighlight>~~
−
−	~~Now individual parameters can be set, and any setting that isn't defined will inherit the value used in the BASE configuration. The below options were set in the 3x_replication configuration~~
−
−	~~<syntaxhighlight>~~
−	~~[root@q01 ~]# qmgmt volume config export 3x_replication~~
−	~~configuration_name: "3x_replication"~~
−	~~base_configuration: "BASE"~~
−	~~volume_metadata_configuration {~~
−	~~replication_factor: 3~~
−	}
−	~~default_config {~~
−	~~placement {~~
−	~~required_device_tags {~~
−	~~tags: "hdd"~~
−	}
−	~~forbidden_device_tags {~~
−	}
−	~~prefer_client_local_device: false~~
−	~~optimize_for_mapreduce: false~~
−	}
−	}
−	~~</syntaxhighlight>~~
−
−	This will create 3 replications of data and metadata, as well as only place data on devices tagged with "hdd". The use of tags allows for finer control of what data is placed on what devices. In this example all data is placed on HDDs and not on SSD storage.
−
−	* Web console
−
−	The Web console only allows new sub-configurations to be created, i.e configurations that inherit from another. To create a new sub-configuration, navigate to 'Volume Configurations' and tick the box next to BASE. Then from the drop down menu select 'Add new sub-configuration'
−
−	~~[[File:quobyte_add_subconfig.png\|551px]]~~
−
−	~~===Creating Volumes===~~
−
−	~~Volumes are created either from the CLI or through the web console.~~
−
−	* CLI
−	~~The generic command used to create volumes is~~
−	~~<syntaxhighlight>qmgmt volume create <volume name> <user> <group> <volume configuration></syntaxhighlight>~~
−
−	~~In the test bed 3 volumes were created using different volume configurations. They were created by running the following commands~~
−
−	~~<syntaxhighlight>~~
−	~~qmgmt volume create home_vol root root 3x_replication~~
−	~~qmgmt volume create scratch_vol root root ssd_performance~~
−	~~qmgmt volume create archive_vol root root 8+3_erasure~~
−	~~</syntaxhighlight>~~
−
−	~~===Mounting Volumes===~~
−
−	~~Volumes can be mounted on any server that the quobyte-client package is installed. There is a CLI tool mount.quobyte used to mount the quobyte volumes.~~
−	~~The command takes a list of registry servers and volume to mount as well as the directory to mount the volume to. So to mount the home_vol above to /home~~
−
−	~~<syntaxhighlight>~~
−	~~mount.quobyte q01:7861,q02:7861,q03:7861,q04:7861/home_vol /home~~
−	~~</syntaxhighlight>~~
−
−	~~This can be repeated to mount any other volumes~~
−
−	~~<syntaxhighlight>~~
−	~~mount.quobyte q01:7861,q02:7861,q03:7861,q04:7861/scratch_vol /scratch~~
−	~~mount.quobyte q01:7861,q02:7861,q03:7861,q04:7861/archive_vol /archive~~
−	~~</syntaxhighlight>~~

@@ Line 119: / Line 119: @@
 #  metadataOnly: Indicates that the disk contains metadata and does not contain data.
 #  LocalCache: Indicates that the disk is to be used as a local read-only cache device.
 =Volume Management=

@@ Line 102: / Line 102: @@
 The NSD stanza file should have the following format:
-%nsd: device=DiskName
+  %nsd: device=DiskName
    nsd=NsdName
    servers=ServerList
@@ Line 108: / Line 108: @@
    failureGroup=FailureGroup
    pool=StoragePool
-  usage
+Notes:
-  dataAndMetadata: Indicates that the disk contains both data and metadata. This is the default for disks in the system pool.
+* server list can be ommited in the following cases:
-  dataOnly: Indicates that the disk contains data and does not contain metadata. This is the default for disks in storage pools other than the system pool.
+# For IBM Spectrum Scale RAID, a server list is not allowed. The servers are determined from the underlying vdisk definition
-  metadataOnly: Indicates that the disk contains metadata and does not contain data.
+# For SAN configurations where the disks are SAN-attached to all nodes in the cluster, a server list is optional.
-  LocalCache: Indicates that the disk is to be used as a local read-only cache device.
 =Volume Management=