Adm2000 Lab Guide
Adm2000 Lab Guide
Lab Guide
September 2015, v5.0
This Guide is protected under U.S. and international copyright laws, and is the exclusive property of
MapR Technologies, Inc.
2015, MapR Technologies, Inc. All rights reserved. All other trademarks cited here are the property of
their respective owners.
ii
Get Started
Icons Used in This Guide
This lab guide uses the following ions to draw attention to different types of information:
Note: Additional information that will clarify something, provide additional
details, or help you avoid mistakes.
Lab Requirements
You will need the following to complete the labs for this course:
Access to a physical or virtual cluster with at least 4 nodes. Instructions on setting up virtual
clusters using either Amazon Web Services (AWS) or Google Cloud Platform (GCP) are included
with the course files.
Visit http://doc.mapr.com/display/MapR/Preparing+Each+Node for information on required
specifications for the nodes.
SSH access to the nodes. For Mac users, this is built into the standard terminal program.
Windows users may need to download and install an additional utility for this (such as PuTTY). If
you are using GCP, you can SSH into the nodes from the GCP console.
You can download PuTTY at http://www.putty.org.
Note: Make sure that you can access the nodes via SSH before starting the labs.
Get Started
Each node in your cluster will have both an internal IP address, and an external
IP address. To view them, log into the AWS console and click on the node.
Use the internal IP address to connect from one node in the cluster to
another.
Default <user>
The default AWS user name is ec2-user. Whenever you see <user> in a
command sample in the lab guide, substitute ec2-user.
Log in as root
The user ec2-user has sudo privileges. To log into a node as root, first log in
as ec2-user and then sudo to root:
$
sudo
-i
SSH access
To connect to a node in your cluster, use the .pem file that was provided with
the course materials (or that you downloaded when you created your AWS
instances). For example:
ssh
i
<.pem
file>
ec2-user@<external
IP
address>
Get Started
Each node in your cluster will have both an internal IP address, and an external
IP address. To determine the IP addresses of your nodes, run this command
from your terminal window (where you installed the Google Cloud SDK):
gcloud
compute
instances
list
Default <user>
To connect to the node from a system outside the cluster, such as your
laptop, use the SSH button in the Google Developer's Console (see the
information below on SSH access).
Use the internal IP address to connect from one node in the cluster to
another.
The default user name will be based on the Google account under which your
project was created. If you are unsure of the default user name, connect to one
of your GCP nodes (see SSH access, below). The login prompt displayed will
include your user name. For example:
[username@node1
~]$
Log in as root
The default user has sudo privileges. To log into a node as root, first log in as
the default user and then sudo to root:
$
sudo
-i
SSH access
Overview
The purpose of this lab is to make sure you can connect to the nodes you will be using throughout the
course. This is required for all of the remaining labs.
Get Started
Note: Instructions in this section are specific to the nodes that are used in the classroom
training. If you are in the classroom training, make sure you download the course files to your
system before beginning.
If you are taking the on-demand training, you will need to provide you own nodes and the
method for connecting to those nodes may differ from the instructions presented here.
If you are using GCP nodes, you can SSH into them directly from the Google
Developer's Console.
If you are using AWS nodes, you should have downloaded the .pem file when you
created your instances. Windows users of AWS nodes will need to convert the .pem
file to a .ppk file: instructions for doing that can be found in the AWS documentation,
last seen here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html.
Get Started
3. A new screen will appear when you click Auth in the menu. Browse for the .ppk file (supplied
with the course files for classroom training), and click Open to open a terminal window.
4. Once the terminal window opens up, log in as the default user (ec2-user, for AWS nodes). A
password is not required since you are using the .ppk file to authenticate. Once logged in, you
will see the command prompt, and be able to sudo to the root user.
5. Log out of the node, and repeat for the other nodes in your cluster. You can also open multiple
PuTTY windows to have access to multiple nodes at the same time.
Get Started
Once logged in, you should see the command prompt. You should also be able to sudo to the
root user:
$
sudo
-i
3. Log out of the node, and repeat for the other nodes in your cluster.
Note: Follow the instructions in Appendix A of the lab guide for details on how to set up
passwordless SSH. These instructions were written for the AWS nodes that are used in the
classroom training; this procedure may be different for on-demand training students.
Classroom students: Check with your instructor before proceeding, as passwordless SSH may
have been set up in advance.
For example:
3. Test that clush provides passwordless access to all the nodes of the cluster:
#
clush
-a
date
2. View the output file to evaluate your cluster hardware. Look for hardware or firmware levels that
are mismatched, or nodes that don't meet the baseline requirements to install Hadoop.
1-2
1-3
1. Type the command below to list the unused disks on each node. These are the disks that IOzone
will run against, so be sure to examine the list carefully.
#
clush
-ab
/root/pre-install/disk-test.sh
2. After you have verified the list of disks is correct, run the command with the --destroy argument:
#
clush
-ab
/root/pre-install/disk-test.sh
--destroy
Note: In the lab environment, the test will run for 15-20 minutes, depending on the
number and sizes of the disks on your nodes. In a production environment with a
larger cluster, it can take significantly longer.
The test will generate one output log for each disk on your system. For example:
xvdb-iozone.log
xvdc-iozone.log
xvdd-iozone.log
3. If there are many different drives, the output can be difficult to read. The summIOzone.sh script
creates a summary of the output. Run the script and review the output:
#
clush
-a
'/root/pre-install/summIOzone.sh'
Note: The script assumes that the log files are in the present working directory, so the
script must be run from the directory that contains the log files.
Keep the results of this and the other benchmark tests for post-installation comparison.
Q:
What type(s) of nodes (data, control, or control-as-data) will your cluster have?
A:
Since you only have three nodes, you will need to spread the control services (such as
ZooKeeper and CLDB) out over all of the nodes. To do this and still have room for data,
you will need to use control-as-data nodes.
1-4
Warden
NodeManager
Resource Manager
HistoryServer
NFS
MFS
CLDB
ZooKeeper
Fill out the chart below to show where the various services will be installed on your cluster:
Warden
NodeManager
Resource Manager
HistoryServer
NFS
MFS
CLDB
ZooKeeper
Try this! How would you configure a 10-node cluster with the same requirements?
1-5
Preparation
1. Log in as root on the master node, then download and run the mapr-setup script:
#
wget
http://package.mapr.com/releases/installer/mapr-setup.sh
#
bash
./mapr-setup.sh
This script will prepare the node to use the browser-based installer.
Note: If you see the message, Error:
Nothing
to
do, you can ignore it.
Accept the defaults for the mapr admin user, UID, GID, and password. Enter mapr as the
password, then re-enter it confirm:
2. When the script completes, point your browser to the node at port 9443:
Note: For virtual clusters, the mapr-setup.sh script may display the internal IP address
here in this screen. Make sure you use the external IP address of the node.
3. Open the requested URL to continue with the installation. Ignore any warnings you receive about
the connection not being secure, and log into the installer as the user mapr (the password will
also be mapr, unless you changed it when running the mapr-setup.sh script).
4. From the main MapR Installer screen, click Next in the lower right corner to start moving through
the installation process. The first screen is Select Version & Services.
1. From the MapR Version pull-down menu, set the MapR Version to 5.0.0.
2. In the Edition field, select Enterprise Database Edition (this is the default).
3. Under License Option, select Add License After Installation Completes.
4. In the Select Services section, the option Data Lake: Common Hadoop Services is selected by
default as the Auto-Provisioning Template. Perform the following actions to review services,
and to set them for the course:
a. Click Show advanced service options.
This displays the services that will be installed with the selected template.
2-2
Database Setup
The entries displayed on this screen will depend on which services were selected on the previous screen
(a database needs to be selected for Hue, Oozie, Metrics, or Hive). Since we did not select any services
requiring a database setup, there will be no database to configure.
2-3
1. The MapR Administrator Account section will show the values you entered when you ran the
setup script. In the Password field, enter the password for the mapr user.
2. In the Cluster Name field, enter a name for your cluster. If you are in the instructor-led course,
use the cluster name that was assigned to you in the .hosts file to be sure your cluster name is
not the same as another student's.
3. Click Next to advance to the Configure Nodes screen.
Configure Nodes
This screen is where you define the nodes to include in your cluster, the disks that will be used, and the
authentication method. The hostname of the install node will already be filled in for you.
2-4
1. In the Nodes section, enter the fully qualified hostnames of the three nodes that will be in your
cluster, one per line. The hostname of the install node will generally be filled in for you.
th
Caution! Install the cluster on just your first 3 nodes. The 4 node will be used in a
later lab, and should not have MapR installed on it at this time.
For example:
2. In the Disks section, enter the names of the disks that will be used by the cluster. You can run
this command on a node to verify the disks on your system:
#
fdisk
l
|
grep
dev
Enter the disks as a comma-separated list. For example:
Then:
2-5
Verify Nodes
Verify Nodes verifies that each node can be reached and meets the minimum requirements. When
complete, the node icons will display as green (ready to install), yellow (warning), or red (cannot install).
1. To check the status of a yellow or red node, click on the node icon. A box on the right-hand side
of the screen will appear, with details of any warnings or errors found. For example:
Note: In the screenshot above, there are warnings because the nodes do not have
swap space. This will often be the case with virtual AWS or GCP clusters. You can
proceed with warnings, but in a production environment it is best to correct any issues
and re-verify the nodes.
2. When ready, click Next to advance to the Configure Service Layout screen.
2-6
1. Click View Node Layout to see which services will be installed on which nodes. After reviewing
the layout, click Close.
2. Click Advanced Configuration and review the screen. Services are divided into logical
groupings; you can change these groupings, or add groups of your own. Make some changes to
the service layout for practice:
a) Look for the DEFAULT group. Drag the NFS service icon to the row below it, to make a
new group.
b) Change the group name to NFS.
c) In the Nodes column of the new group, click the Modify button.
d) Select one or more nodes to be in the NFS group by clicking on the node icons.
e) Click OK. You now have those nodes in the NFS group so the NFS service will be
installed on them.
f)
Click the trashcan icon to the right of the NFS group to delete it. Click OK to verify the
deletion.
2-7
g) Scroll up to the top of the page. The NFS service icon is now unprovisioned and must be
placed in a group before the installation can proceed.
Caution! The service layout you configured for Company ABC does not list all of the
services that will go on a MapR cluster. Do not delete services from this screen that do
not appear on your worksheet; just make sure that the services that DO appear on your
worksheet are laid out the way you intend.
Note: Make note of which node is running the JobHistoryServer, and record its external
IP address. You will need this information later when viewing job history.
5. Drag the Webserver service into the DEFAULT group, so it will be installed on all three nodes.
6. Click Save to save the service layout, then click Install to start the installation process.
Installing MapR
The installation will take approximately 30 minutes to complete on a 3-node lab cluster. Time
required in a production environment will vary based on what is being installed, and the number of nodes.
When the install is complete, click Next. Since you did not install a license at the start of the installation,
a page will appear letting you know that a license must be entered. Click Next to advance to the final
step of the installation.
2-8
4. Some nodes in the cluster may have orange icons in the node heatmap, indicating degraded
service. This is normal since some services were started before the license was applied. You will
typically have to restart CLDB and NFS Gateway services.
To restart any failed services:
a. Find the Services panel on the right side of the dashboard, and note any services that
have failures:
b. Click on the red number in the Fail column to see a list of nodes where the specified
service has failed. Select all the nodes and click the Manage Services button at the top.
2-9
c.
Find the service you want to restart. From the drop-down list next to the service name,
select Restart. Then click OK.
5. Back at the Services pane, check to see that all the NFS Gateway services are running. You may
not see failures: instead, you may just see no active NFS services:
If they are not running, restart them as you did with the CLDB service.
6. Return to the dashboard you should see all green node icons (you may have to refresh the
screen).
2-10
Lessons Learned
Some of the key takeaways from this lesson are listed below.
The MapR installer will guide you through the installation process, and make sure that
interdependencies are not violated.
The MapR Installer verifies that nodes are ready for installation before proceeding.
Plan your service layout prior to installing the MapR software. In particular:
Make sure that you have identified where the key control services (CLDB, ZooKeeper,
ResourceManager) will be running in the cluster.
Ensure that you have enough instances of the control services to provide high availability
for your organization if it is required.
After installing MapR, apply a license and restart any failed services.
2-11
2. Verify that the new mount point directory and volume exist:
#
hadoop
fs
-ls
/
3. Switch to the mapr user to run the script:
#
su
mapr
4. Run the TeraGen command:
yarn
jar
/opt/mapr/hadoop/hadoop-2.7.0/share/hadoop/mapreduce/hadoop-
mapreduce-examples-2.7.0-mapr-1506.jar
teragen
500000
/benchmarks/teragen1
This will create 500,000 rows of data.
5. Open the MCS to the dashboard view so you can watch node utilization while the next step
(TeraSort) is running.
a. At the top of the dashboard, set the heatmap to show Disk Space Utilization so you will
see the load on each node. It should be spread relatively evenly across the cluster.
Hotspots suggest a problem with a hard drive or its controller.
b. On the right-hand side of the dashboard, the YARN section will display information on the
job as it is running.
Note: If you cannot connect, make sure you are using the external IP
address of the node that is running the JobHistoryServer service.
3-2
c.
Jobs are listed with the most recently job at the top. Click the Job ID link to see job
details. It will show the number of map and reduce tasks, as well as how many attempts
were failed, killed, or successful:
d. To see the results of the map or reduce tasks, click on Map in the Task Type column.
This will show all of the map tasks for that job, their statuses, and the elapsed time.
You can keep drilling down to get detailed information on each task in the job.
Lessons Learned
Running benchmark tests after installation gives you a performance baseline that you can refer to
later, and helps you spot any concerns early on.
3-3
4. Type in the topology path, /data/rack1, to create and assign the new topology. Then click OK.
To determine the node's server ID, run maprcli node list -columns id.
Overview
The marketing and R&D departments will be sharing nodes in the cluster, but still want to keep access to
their data isolated. To do this, you will create directories and volumes in the cluster for the departments
and their users.
Name
Type
UID
GID
mkt
group
--
6000
miner
group
--
6001
sharon
user
600
6000
keith
user
601
6000
rnd
group
--
7000
cobra
group
--
7001
rattler
group
--
7002
jenn
user
700
7000
tucker
user
701
7000
mark
user
702
7000
marje
user
703
7000
porter
user
704
7000
4-2
Before they can be assigned volumes or permissions in the cluster, they must exist at the OS level on
each node in the cluster. They must have the same name, UID, and GID on each node.
1. Log into your master node as root.
2. Create UNIX users and groups for all of the entities in the table above. Use clush to facilitate the
operations. For example:
#
clush
-a
clush>
groupadd
mkt
-g
6000
clush>
useradd
sharon
-g
6000
-u
600
clush>
clush>
quit
The MCS (navigate to MapR-FS > Volumes and click New Volume)
4-3
Volume Name
AE
Mount Path
Advisory
Quota
Hard
Quota
miner-dev
miner
/projects/mkt/miner/miner-dev
70 GB
100 GB
miner-prod
miner
/projects/mkt/miner/miner-prod
100 GB
130 GB
cobra-dev
cobra
/projects/rnd/cobra/cobra-dev
70 GB
100 GB
cobra-prod
cobra
/projects/rnd/cobra/cobra-prod
100 GB
130 GB
rattler-dev
rattler
/projects/rnd/rattler/rattler-dev
200 GB
220 GB
rattler-prod
rattler
/projects/rnd/rattler/rattler-prod
250 GB
300 GB
5. From the UNIX command line on the master node, change the group for each volume to its
respective department:
#
hadoop
fs
-chgrp
-R
mkt
/projects/mkt
#
hadoop
fs
-chgrp
-R
rnd
/projects/rnd
6. Verify that the groups have changed:
#
hadoop
fs
-ls
-R
/projects /mkt
#
hadoop
fs
-ls
-R
/projects/rnd
Lessons Learned
At a minimum, configure a rack topology that puts each node into a specific rack. You can create
more specific topologies if you need to segregate data onto specific nodes.
Set up a topology for decommissioned nodes, to facilitate node maintenance and removal.
Volumes are a key management tool create volumes liberally (and early) to organize your data.
Assign a high-level topology (such as /data) to volumes, unless you need a volume's data to be
on a specific group of nodes.
Use accountable entities to establish the user or group responsible for the volume's disk usage.
When specifying a mount path for a volume, the parent directories must exist. Use the command
hadoop fs
mkdir if needed to create the directories.
4-4
Note: The Critical data schedule takes a snapshot every hour, at the top of the hour.
Depending on what time it is when you apply the schedule, it may take up to an hour for
the snapshot to be created.
5. Navigate to MapR-FS > Schedules. You will see that the schedule you selected for the volume
is listed as In use. Click the green checkmark to see information about the schedule including
when the snapshot will expire.
6. Click the drop-down box that shows Hourly, and change it to Every 5 min. Change the Retain
for field to be 1 hour, and click Save Schedule. This changes the Critical data schedule, for
every volume that is using the schedule. Now a scheduled snapshot will be taken every 5
minutes, instead of at the top of the hour.
7.
Click the schedule name to see a list of all volumes that are associated with that schedule.
5-2
4. Click New Snapshot. The Create New Snapshot dialog box appears. Enter Manual_1 as the
name of the snapshot, and click OK.
5. Navigate to MapR-FS > Snapshots. The snapshot you took should be listed there.
5-3
6. Since the cluster file system is mounted, you can also use Linux commands to see the status of
the file. Use the ls command to see that the file has been restored:
#
ls
/mapr/<cluster
name>/NFStest/<file
name>
Note: Remember that "/" in the hadoop command is the root of the cluster file system,
and the "/" in Linux is the root of the local file system. This is why different paths are
specified for the hadoop
-fs
-ls command, and the Linux ls
command.
5-4
Mirror Name
NFStest-mirror
NFStest
Mount Path
/NFStest-mirror
Topology
/data
Replication
NS Replication
Mirror Schedule
Normal data
3. Click OK. This creates and mounts the local mirror volume.
4. Navigate to MapR-FS > Mirror Volumes. Verify that your mirror volume appears.
Q:
The Last Mirrored and % Done columns do not contain information. Why not?
A:
Your actions created the mirror volume, but did not start the mirroring process.
If you want the volume to mirror right away, you can manually start the mirror.
Otherwise, it will start at the time specified in the schedule (which you can see
by navigating to MapR-FS > Schedules).
Follow these steps to force the mirror volume to start synchronizing prior to the scheduled time:
1. Navigate to MapR-FS > Mirror Volumes.
2. Check the box next to the mirror volume you just created.
3. Click Volume Actions. From the pull-down menu, select Start Mirroring. This will start the
synchronization process.
5-5
st
This sets the action to occur on March 31 each year, and be kept for one year.
5. Click Add Rule to add another rule to your schedule. Add a total of 3 more rules, that will:
th
th
st
6. Click Save Schedule when you have fully defined the schedule. The newly created schedule
appears in the schedule list, and is available for mirrors and snapshots.
Note: Schedules are available to be used for either snapshots or mirrors. If a schedule
is applied to a mirror volume, the retain time is ignored (the mirror will not expire). If the
schedule is used for a snapshot, the snapshot will automatically be deleted when the
retain interval is met.
5-6
Every node in each cluster must be able to resolve all nodes in remote clusters, either
through DNS or entries in /etc/hosts.
The MapR user for both the local (source) and remote (destination) clusters must have
the same UID.
You need to have dump permission on the source volume, and restore permissions on
the mirror volumes at the destination cluster.
5-7
3. Click the + symbol next to the name and verify that the destination cluster is listed under
Available Clusters.
4. Click on the link for the destination cluster to open the MCS for the destination cluster.
Note: For an AWS cluster, it will attempt to connect using the internal IP address, which
will fail. You will need to connect using the node's external IP address.
5-8
For the Source Volume Name, enter the name of the volume on the source cluster that you
want to mirror.
For the Source Cluster Name, enter the name of the source cluster (once you start typing,
the cluster name should appear so you can select it).
For the Mount Path, enter the path on the destination cluster where the mirror volume will be
mounted.
Under Permissions, make sure that the user mapr has restore permissions.
4. Click OK to create the volume. The volume should appear in your volume list: navigate to
MapR-FS > Mirror Volumes to verify.
5-9
Lessons Learned
With the cluster file system mounted, you can use standard Linux commands to copy data into
the cluster.
Snapshots can be created manually, or on a schedule. Snapshots that are created manually do
not have a set expiration date. Snapshots that are created on a schedule will have an expiration
date, but then can be preserved before they expire if you want to keep them longer.
Mirror volumes must be synchronized after they are created. They can be synchronized
manually, or with a schedule.
When a schedule is applied to a mirror volume, the retain time is ignored (data in mirror volumes
does not expire; the mirror is updated with new data each time it is synchronized).
Remote mirrors are set up between two clusters, typically for disaster recovery purposes.
With a local mirror volume, the data is pushed from the source volume to the mirror volume. With
a remote mirror volume, data is pulled from the remote mirror.
5-10
You can also use the drop-down list to filter by certain alarm types. For example, if you select
Node Alarm Heartbeat Processing Slow, you will see alarms on any nodes that have a slow
heartbeat:
3. Click on a node icon to see more on the node's status. The view shows information on:
Database operations
MapR-FS disks
System disks
The pane lists services running on the cluster. In particular, look for any numbers in the Fail
column.
2. Click a failed service: a screen displays that shows which node has the failed service. From here,
you can start or restart the service.
6-2
3. A list of services displays. From the drop-down list next to a service name, choose to start, stop,
or restart the service on the selected nodes. Then click OK.
4. You can also start and stop services from the command line:
#
maprcli
node
services
-<name>
start|stop|restart
nodes
<list
of
nodes>
6-3
Note: You will perform this procedure on a "healthy" disk, since you do not have any failed
disks in your lab cluster. The procedure is the same for a disk that has actually failed.
1. When a drive fails, a Data Under Replicated alarm is raised. Check the alarm in the MCS to
determine which node had a disk failure.
2. If there was an actual disk failure, you would view the logs to determine the cause, to make sure
the disk needs to be replaced. The log files are located at /opt/mapr/logs/faileddisk.log.
3. In the MCS, navigate to Cluster > Nodes.
4. Click the name of the node with the failed drive: the node properties display (for the purposes of
this lab, you can select any of the nodes).
5. Scroll down to MapR-FS and Available Disks.
6. Scroll to the right and check the Storage Pool ID. Make note of all of the disks included in the
same storage pool:
7. Check the box next to the failed disk, and click Remove Disk(s) to MapR-FS.
6-4
8. Click OK. All of the disks in the storage pool will be brought offline to the cluster. All of the disks
in the storage pool will be removed from MapR-FS, and the File System column will be empty.
The Used column will show 0%:
Decommission a Node
Use the /decommissioned topology to take a node offline, either for retirement or to perform extended
maintenance.
1. In the MCS, navigate to Cluster > Nodes.
2. Check the box next to the node you will take offline.
3. Click Change Topology.
4. In the drop-down list, select the /decommissioned topology. Then click OK. The node is moved
to the decommissioned topology. Since the containers on the node belong in a different topology
(such as /data), the system will initiate the process of creating new copies of the data on available
nodes.
6-5
Note: These instructions are specific to the classroom training, which uses AWS nodes for the
clusters. If you are taking the on-demand course and supplying your own nodes, you will need
to make adjustments.
PasswordAuthentication yes
PermitRootLogin yes
If the file also contains either of these lines, delete them or comment them out:
PermitRootLogin
no
PasswordAuthentication
no
4. Save the file, and run this command:
#
sshd
t
If no output is returned, proceed. If there are any errors, correct them before continuing.
5. Restart the sshd service:
#
service
sshd
restart
2. Copy the generated key pair into place on all three nodes (including the master). When prompted
for the password, enter mapr.
#
ssh-copy-id
root@<master
node
IP
address
or
hostname>
#
ssh-copy-id
root@<node1
IP
address
or
hostname>
#
ssh-copy-id
root@<node2
IP
address
or
hostname>
The screenshot below shows the type of output generated:
3. Now ssh from the master node into each other node as root you should be able to connect
without an authentication file:
#
ssh
root@<node
internal
IP
address
or
hostname>
A-2