SSL Connection to RDS Instances in phpMyAdmin

By , September 1, 2015 6:56 am

Setting up SSL connection between phpMyAdmin and the RDS MySQL server is quite straight forward. Below is a demo setup on Amazon Linux with phpMyAdmin 4.4.14. The web server is Apache with PHP 5.

First of all we download and unzip phpMyAdmin. At the same time we download the root certificate for RDS to the phpMyAdmin folder:

$ cd /var/www/html
$ wget https://files.phpmyadmin.net/phpMyAdmin/4.4.14/phpMyAdmin-4.4.14-all-languages.zip
$ unzip phpMyAdmin-4.4.14-all-languages.zip
$ cd phpMyAdmin-4.4.14-all-languages.zip
$ cp config.sample.inc.php config.inc.php 
$ wget https://s3.amazonaws.com/rds-downloads/rds-ca-2015-root.pem

Now edit config.inc.php, using the following configurations for the “First server”, which is your RDS instance.

/*
 * First server
 */
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'instance-name.xxxxxxxxxxxx.ap-southeast-2.rds.amazonaws.com';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;
$cfg['Servers'][$i]['ssl'] = true;
$cfg['Servers'][$i][''] = '/var/www/html/phpMyAdmin-4.4.14-all-languages/rds-ca-2015-root.pem';

You will probably need to restart httpd to make things work.

$ sudo service httpd restart

At this point, you can use phpMyAdmin to login to your RDS instance. After you login, us the following SQL query to verify the SSL connection:

show status like 'Ssl_cipher';

If you see the following result, the SSL connection is successful:

Variable_name 	Value 	
Ssl_cipher 	AES256-SHA

机智的球球

By , August 29, 2015 1:12 pm

球球四岁,在公园里跟一个大一点的女孩一起玩。球球问她:“How old are you?”

女孩回答说:“I am 10.”

球球说:“My sister is 10. She is 2 older than you.”

太机智了!

Running DEWE v2 on AWS

By , August 17, 2015 5:51 am

[Introduction]

DEWE v2 is a pulling-based workflow execution framework designed with public clouds (for example, AWS) as the target execution environment. With AWS EC2, a homogenous computing environment can be creating by launching a set of EC2 instances with the same instance type in the same availability zone (probably in the same placement group). Statistically, these EC2 instances have the same computing resource in terms of CPU, memory, storage, and networking. DEWE v2 takes advantages of this homogeneity to reduce the scheduling overhead in traditional workflow execution frameworks (such as Pegasus + HTCondor) with a pulling approach. Test results with five 6.0 degree Montage workflows running in parallel indicates that DEWE v2 can achieve 80% speed up as compared to the Pegasus + HTCondor solution on a single node cluster.

DEWE v2 was first published on the 44th International Conference on Parallel Processing (ICPP-2015) in Beijing (China) in the following paper:

Qingye Jiang, Young Choon Lee, Albert Y. Zomaya, “Executing Large Scale Scientific Workflow Ensembles in Public Clouds“, 44th International Conference on Parallel Processing (ICPP-2015), Beijing, September 2015

This blog post provides a Getting Started guide on running DEWE v2 on AWS.

[Single Node Configuration]

To get started with DEWE v2, you will need to have an account on AWS. In your EC2 Console, navigate to the N. Virginia (us-east-1) region and click on the blue “Launch Instance” button. In “Step 1: Choose an Amazon Machine Image (AMI)” page, click on “Community AMIs” and search for “DEWE.v2 ICPP”, you will be able to find the demo AMI we prepared for ICPP 2015, as shown in the screen capture below.

屏幕快照 2015-08-15 下午7.32.52

Select the AMI with the name “DEWE.v2 for ICPP 2015” and proceed to “Step 2: Choose an Instance Type”. In this tutorial, please use r3.xlarge or a larger instance type, because we will need some decent instance-store storage volume to run a 6.0 degree Montage workflow as an example. In “Step 3: Configure Instance Details”, you will need to launch the instance into a public subnet with a public IP address, this way you can SSH into the instance to run DEWE v2. In “Step 4: Add Storage” please make sure that you add the instance-store volume (Instance Store 0) to the EC2 instance, otherwise the EC2 instance will be launched without the instance-store volume. If you need assistance in getting started with AWS EC2, please refer to the following AWS Documentations:

Getting Started with Amazon EC2 Linux Instances

Connecting to Your Linux Instance Using SSH

When the EC2 instance becomes “running” and passes 2/2 health checks, SSH into the EC2 instance using username “ubuntu” with your key pair. First of all we will format and mount the instance-store volume, then copy the example 6.0 degree Montage workflow to the instance-store volume, as below:

sudo mkfs.ext4 /dev/xvdb
sudo mount /dev/xvdb /data
sudo chown -R ubuntu:ubuntu /data
cd /data

cp ~/TestData/DEWE.v2_Montage_6.0_Example.tar.gz .
tar zxvf DEWE.v2_Montage_6.0_Example.tar.gz
cd ~/DEWE.v2/bin

Now we have the example 6.0 degree Montage workflow in the /data/DEWE.v2_Montage_6.0_Example folder. We will go ahead and set up DEWE v2 so that it will run. First we run “ifconfig eth0″ to determine the private IP address of the EC2 instance. Then we edit config.properties and replace “master=10.0.4.15″ with the correct private IP address of your EC2 instance. Apart from that, you don’t need to change any other parameters in this config file.

Now run the following command to start the DEWE v2 master daemon, worker daemon, and monitoring daemon. When starting the monitoring daemon, you will need to specify which storage volume to monitor. In this example, we are using instance-store volume /dev/xvdb to host the workflow. Therefore, we use “xvdb” as the parameter for the monitoring daemon:

./dewe.sh master start
./dewe.sh worker start
./dewe.sh monitor xvdb start

In the same folder, you will notice that each daemon produces a PID file containing the pid of the process (for example, master.pid, worker.pid, and monitor.pid), as well as a log file containing the output from the process. The file name of the log file contains the private IP address of the EC2 instance, as well as the date and time the daemon is started (for example, worker-ip-172-31-27-138-2015-08-15-10-02-31.log).

Now we submit the example 6.0 degree Montage workflow to DEWE v2 for execution. The format of the command is “./dewe.sh submit workflow_name workflow_folder”. For example:

./dewe.sh submit Montage_6.0 /data/DEWE.v2_Montage_6.0_Example

You can check the status of the execution using the “./dewe.sh status” command. For example:

./dewe.sh status

You might see multiple entries of workflows in the status output. Those are the records from our own testings. You will need to look at the time stamps to determine which entry is really your own workflow.

You can use the “top” or “isolate 1″ commands to observe what your EC2 instance is doing while running your workflow. On an r3.xlarge instance, you should expect around 25 minutes before DEWE v2 finishes executing a 6.0 degree Montage workflow. (A 6.0 degree Montage workflow contains 8,586 jobs, 1,444 input files with a total size of 4.0 GB, and 22,850 intermediate files with a total size of 35 GB. The majority of these 8,586 jobs are copies of a few short-running jobs such as mProjectPP, mDiffFit and mBackground.)

top
iostat 1

When the execution of the workflow is completed, you can stop the master, worker, and monitoring daemons using the following commands:

./dewe.sh master stop
./dewe.sh worker stop
./dewe.sh monitor xvdb stop

At this point it would be worthwhile to look into the log files produced by the various daemons. In particular, you should look into the log file produced by the monitoring daemon to understand the status of computing resource utilization. The fields in this log file include UNIX timestamp (in seconds), the average number of concurrent threads observed on the operating system level, the percentage of CPU utilization, the number of disk I/O operations (the sum of reads and writes) per second, disk read throughput (KB/s), and disk write throughput (KB/s).

After you finish this exercise, you should terminate the EC2 instance in a timely manner to avoid further charges.

[Multi-Node Configuration]

In this step, we will create a more complex set up – a cluster with three compute nodes with MooseFS (a POSIX-compliant distributed file system) as the underlying storage. In order to do so, we will launch a separate MooseFS master node to manage the storage nodes. The storage nodes will be at the same time DEWE v2 worker nodes. One of the worker nodes also acts as the DEWE v2 master node by running the DEWE v2 master daemon.

We will need to launch the MooseFS master node first. In your EC2 Console, navigate to the N. Virginia (us-east-1) region and click on the blue “Launch Instance” button. In “Step 1: Choose an Amazon Machine Image (AMI)” page, click on “Community AMIs” and search for “DEWE.v2 MooseFS”, you will be able to find the demo AMI we prepared for ICPP 2015, as shown in the screen capture below. You will need to select the AMI with the name “DEWE.v2 MooseFS Master for ICPP 2015″. The MooseFS master node does not need a whole lot of processing power, so I select a t2.medium instance type for this exercise.

屏幕快照 2015-08-15 下午9.14.08

Now SSH into the MooseFS master node. The first thing you will need to do is to use the “ifconfig eth0″ command to figure out the private IP address of the MooseFS master node. Then you will need to edit /etc/hosts and update the IP address for “mfsmaster” with this private IP address.  After that you will need to run the following commands:

cd /var/lib/mfs
sudo cp metadata.mfs.back metadata.mfs
sudo service moosefs-ce-master start
mfscli -SCS

If you see outputs similar to the following, your MooseFS master node is now successfully running.

屏幕快照 2015-08-16 下午3.14.50

Now we will launch three additional EC2 instances to run DEWE v2. Similar to what we do in the single node configuration, we click on “Community AMIs” and search for “DEWE.v2 ICPP 2015″ to search for the AMI to use. In “Step 2: Choose an Instance Type” we choose c3.2xlarge, which has 2 x 40 GB instance-store volumes. In “Step 3: Configure Instance Details” we specify 3 for the number of instances, this way we do not need to launch 3 instances one by one (which is not a problem but troublesome). On the same page, we click on “Advanced Details”, and paste the following into the text area for “User data”. It should be noted that you should replace 172.31.31.83 with the private IP address of your MooseFS master node.

#!/bin/bash
cd /home/ubuntu/bin
./mfs_setup.sh 2 172.31.31.83

In “Step 4: Add Storage”, please make sure that you have both “Instance Store 0″ and “Instance Store 1″ for your EC2 instance. Otherwise the above-mentioned cloud-init script will fail. (If you login to the EC2 instance and take a look at the content of /home/ubuntu/bin/mfs_setup.sh, you will see that the shell scripts takes two parameters – the first parameter indicates the number of instance-store volumes (0, 1 or 2), and the second parameters indicates the private IP address of the MooseFS master node. If you select an instance type with only 1 instance-store volume, the command to use will be “./mfs_setup.sh 1 172.31.31.83″.)

It is very important that the security group being used on the MooseFS master node and the security group being used on the DEWE v2 compute nodes should allow all traffic between the MooseFS master node and the DEWE v2 compute nodes.

After the DEWE v2 compute nodes became “running”, you should be able to see outputs similar to the following on your MooseFS master node. The MooseFS master node sees three storage nodes, and uses the disk space (/mfshdd) on the the storage nodes to form a shared file system. The shared file system is mounted on each of the three storage as /FoxData.

屏幕快照 2015-08-16 下午4.01.51

Randomly select any one of the three DEWE v2 compute nodes to run the DEWE v2 master daemon. SSH into this node using username “ubuntu”, do an “ifconfig eth0″ to determine its private IP address. Then we edit config.properties and replace “master=10.0.4.15″ with the correct private IP address of your EC2 instance. Apart from that, you don’t need to change any other parameters in this config file. Copy config.properties to /FoxData so that the other two compute nodes can copy it from the shared file system.

cd ~/DEWE.v2/bin
pico config.properties        # This is to edit the configuration file
cp config.properties /FoxData

Now copy some test data to the shared file system:

cd /FoxData/
cp ~/TestData/DEWE.v2_Montage_6.0_Example.tar.gz .
tar zxvf DEWE.v2_Montage_6.0_Example.tar.gz
cp -r DEWE.v2_Montage_6.0_Example Test-1
cp -r DEWE.v2_Montage_6.0_Example Test-2

Now we have two 6.0 degree Montage workflows for testing (Test-1 and Test-2). After that, we start the master, worker, and monitoring daemon, using the following commands:

cd ~/DEWE.v2/bin
./dewe.sh master start
./dewe.sh worker start
./dewe.sh monitor md0 start   # This time we monitor the RAID0 device /dev/md0

Now SSH into the other two DEWE v2 compute nodes, copy the configuration file configure.properties from /FoxData, then start the worker and monitoring daemons (no master daemon).

cd ~/DEWE.v2/bin
cp /FoxData/config.properties .
./dewe.sh worker start
./dewe.sh monitor md0 start   # This time we monitor the RAID0 device /dev/md0

On any of the three DEWE v2 compute nodes, submit the test workflows for execution, using the following commands:

cd ~/DEWE.v2/bin
./dewe.sh submit Test-1 /FoxData/Test-1
./dewe.sh submit Test-2 /FoxData/Test-2

On any of the DEWE v2 compute nodes, check the execution status of your workflows using the following commands:

cd ~/DEWE.v2/bin
./dewe.sh status

You can use the “top” or “isolate 1″ commands to observe what your EC2 instance is doing while running your workflow. On a cluster with 3 x c3.xlarge compute nodes with MooseFS as the underlying distributed file system, the time needed to execute two 6.0 degree Montage workflows is around 25 minutes. After the workflows are completed, back up the log files on all three DEWE v2 compute nodes to a persistent storage (such as AWS S3) for further analysis. Please remember to terminate all the EC2 instances (the MooseFS master node, and the three DEWE v2 compute nodes) to avoid further charges.

If you want to clean up disk space on the MooseFS shared file system by deleting some folders (in our example, sub-folders under /FoxData), you will need to run a “mfssettrashtime -r 0 folder_name” against the folder you want to delete. The reason is that by default MooseFS does not delete your files from the underlying storage when you issue a “rm” command. Instead, MooseFS simply hides the “deleted” files from you, but keeps them in a trash folder for future recovery. As a result, you do not get your disk space back after issuing a “rm” command, which is very confusing. By running a “mfssettrashtime -r 0 folder_name” command, you tell MooseFS to keep the deleted files for 0 seconds. For example, if you want to delete sub-folder Test-1 completely from /FoxData, you will need to use the following commands:

cd /FoxData
mfssettrashtime -r 0 Test-1
rm -Rf Test-1

Apart from MooseFS, there are several distributed file systems that are commonly used in scientific computing and high performance computing, for example GlusterFS and XtreemFS. In the demo AMI we provided, we have installed MooseFS, GlusterFS, and XtreemFS for you. However, you still need to properly set up and configure the distributed file system before using them. For more information on this topic, please refer to my previous blog entries:

Distributed File System on Amazon Linux – MooseFS

Distributed File System on Amazon Linux – GlusterFS

Distributed File System on Amazon Linux – XtreemFS

[Creating Your Own Workflow]

In this step, we will show you how to create your own workflow that can be executed by DEWE v2. We used the example as shown in the directed acyclic graph (DAG) below to illustrate this process. The entry task of the workflow is a “Sleep” task, which simply sleep for a random amount of time (0 to 100 seconds). Before the “Sleep” task is completed, no other task can be executed. After the “Sleep” task is completed, two “Sleep & Record” tasks will run in parallel, each sleeps for a random amount of time (0 to 100 seconds), and records the random number into it’s own output file a.dat and b.dat. After both “Sleep & Record” tasks are completed, exit task “Add” adds the outputs in a.dat and b.dat, producing a final output file c.dat.

屏幕快照 2015-08-16 下午3.42.48

The workflow for this simple demo can be found on the DEWE v2 compute node in /home/ubuntu/TestData/DEWE.v2_Simple_Demo.tar.gz. You can run this simple demo with the following commands (assuming that /FoxData is the shared file system across all DEWE v2 compute nodes):

cd /FoxData
cp ~/TestData/DEWE.v2_Simple_Demo.tar.gz .
tar zxvf DEWE.v2_Simple_Demo.tar.gz
cd ~/DEWE.v2/bin
./dewe.sh submit Simple_Demo /FoxData/DEWE.v2_Simple_Demo

After the workflow is completed, you should be able to see a.dat, b.dat, and c.dat under folder /FoxData/DEWE.v2_Simple_Demo/workdir.

Now let’s explain the directory structure of a DEWE v2 workflow. Under the project folder, there are three sub-folders – the bin folder contains the executables, the src folder (optional) contains the source code, and the workdir folder (initially empty) contains the input and and output files. Apart from the three folders, dag.xml is the XML representation of the DAG of the workflow, while timeout.xml is the XML representation of the timeout settings for each task.

屏幕快照 2015-08-16 下午10.23.56

The dag.xml usually contains three parts. The first part describes the input and output files, the second part describes each job and the arguments, and the third part describes the precedence dependencies between jobs.

The input and output files are describe as below. a.dat is the output file of a task but is also the input file of another task. b.dat is the output file of a task but is also the input file of another task. c.dat is the output file of a task. (If there is an original input file in the “workdir” folder, then it should be marked as “input”.)

屏幕快照 2015-08-17 上午7.21.32

The jobs and their arguments are described as below. The executable binary for job ID000001 is “Sleep”, and this job has no arguments. The executable binary for job ID000002 is “SleepRecord”, and the argument for this job is “a.dat”. The executable binary for job ID000003 is “SleepRecord”, and the argument for this job is “b.dat”. The executable binary for job ID000004 is “Add”, and the arguments for this job are “a.dat”, “b.dat”, and “c.dat” in the sequence as they appear in the command line.

屏幕快照 2015-08-17 上午7.22.40

The execution directory (current directory) for the jobs is the “workdir” folder. For each job, you can imagine that DEWE v2 first “cd” into the “workdir” folder, then execute the command (with full path) along with the command line arguments. For example, for job ID000004, its execution is similar to the following:

cd /FoxData/DEWE.v2_SimpleDemo/workdir
/FoxData/DEWE.v2_SimpleDemo/Add a.dat b.dat c.dat

Assuming that your job ID000004 takes more than the above-mentioned arguments, you can following this example to describe your job. You can put each argument into one line, or multiple arguments into the same line. In the example below, its execution will be similar to the following:

cd /FoxData/DEWE.v2_SimpleDemo/workdir
/FoxData/DEWE.v2_SimpleDemo/Add 5 String1 String2 a.dat b.dat c.dat

屏幕快照 2015-08-17 上午7.37.29

The precedence dependencies are described as below. Job ID000002 and ID000003 are child jobs of job ID000001. They can not start execution until job ID000001 is completed. Job ID000004 is a child job of both job ID000002 and job ID000003. It can not start execution until both job ID000002 and job ID000003 are completed.

屏幕快照 2015-08-17 上午7.23.22

Configuration file timeout.xml defines the timeout period for some special jobs, while the default timeout period for all jobs is defined in the DEWE v2 configuration file config.properties. In the example below, the timeout period for job name “Sleep” is 150 seconds, while the timeout period for job name “SleepRecord” is 200 seconds. If a particular job has been running for more than its timeout period, DEWE v2 will resubmit the job for execution.

屏幕快照 2015-08-17 上午7.55.42

[Acknowledgements]

This work is supported by the AWS in Education Research Grants. Dr. Young Choon Lee would like to acknowledge the support of the Australian Research Council Discovery Early Career Researcher Award (DECRA) Grant DE140101628.

Running cxxnet on Amazon EC2 (Ubuntu 14.04)

By , August 9, 2015 8:47 am

1. Launch an EC2 instance with the g2.8xlarge instance type, using a Ubuntu 14.04 HVM AMI. When I launched the EC2 instance, I used a root EBS volume of 300 GB (General Purpose SSD) to have a decent disk I/O capacity. With general purpose SSD, you have 3 IOPS for each GB of storage. So 300 GB storage gives me 900 baseline IOPS, with the capability to burst up to 3000 IOPS for an extended period of time.

2. SSH into the EC2 instance and install CUDA driver, as below:

There is a detailed tutorial on this topic available on Github:

https://github.com/BVLC/caffe/wiki/Install-Caffe-on-EC2-from-scratch-(Ubuntu,-CUDA-7,-cuDNN)

3. Install OpenBLAS, as below

$ sudo apt-get install make gfortran
$ wget http://github.com/xianyi/OpenBLAS/archive/v0.2.14.tar.gz
$ tar zxvf v0.2.14.tar.gz
$ cd OpenBLAS-0.2.14
$ make FC=gfortran
$ sudo make PREFIX=/usr/local/ install
$ cd/usr/local/lib
$ sudo ln -s libopenblas.so libblas.so

4. Install OpenCV

There is a detailed documentation available from the Ubuntu community:

https://help.ubuntu.com/community/OpenCV

You will also need to install the header files for OpenCV

$ sudo apt-get install libopencv-dev

3. Install cxxnet, as below

$ cd ~
$ wget https://github.com/dmlc/cxxnet/
$ cd cxxnet
$ ./build.sh

In most cases, the build will fail. You need to customize your Makefile a little bit to reflect the actual situation of your build environment. Below is an example from my environment:

CFLAGS += -g -O3 -I./mshadow/ -I./dmlc-core/include -I/usr/local/cuda/include -I/usr/include -fPIC $(MSHADOW_CFLAGS) $(DMLC_CFLAGS)
LDFLAGS = -pthread $(MSHADOW_LDFLAGS) $(DMLC_LDFLAGS) -L/usr/local/cuda/lib64 -L/usr/local/lib

Then do the make again:

$ make
g++ -DMSHADOW_FORCE_STREAM -Wall -g -O3 -I./mshadow/ -I./dmlc-core/include -I/usr/local/cuda/include -I/usr/include -fPIC -msse3 -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -fPIC -DDMLC_USE_HDFS=0 -DDMLC_USE_S3=0 -DDMLC_USE_AZURE=0 -DCXXNET_USE_OPENCV=1 -DCXXNET_USE_OPENCV_DECODER=1 -fopenmp   -o bin/cxxnet src/local_main.cpp layer_cpu.o updater_cpu.o nnet_cpu.o main.o nnet_ps_server.o data.o dmlc-core/libdmlc.a layer_gpu.o updater_gpu.o nnet_gpu.o -pthread -lm -lcudart -lcublas -lcurand -lblas -lrt -L/usr/local/cuda/lib64 -L/usr/local/lib `pkg-config --libs opencv` -ljpeg
g++ -DMSHADOW_FORCE_STREAM -Wall -g -O3 -I./mshadow/ -I./dmlc-core/include -I/usr/local/cuda/include -I/usr/include -fPIC -msse3 -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -fPIC -DDMLC_USE_HDFS=0 -DDMLC_USE_S3=0 -DDMLC_USE_AZURE=0 -DCXXNET_USE_OPENCV=1 -DCXXNET_USE_OPENCV_DECODER=1 -fopenmp   -o bin/im2rec tools/im2rec.cc dmlc-core/libdmlc.a -pthread -lm -lcudart -lcublas -lcurand -lblas -lrt -L/usr/local/cuda/lib64 -L/usr/local/lib `pkg-config --libs opencv` -ljpeg
g++ -DMSHADOW_FORCE_STREAM -Wall -g -O3 -I./mshadow/ -I./dmlc-core/include -I/usr/local/cuda/include -I/usr/include -fPIC -msse3 -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -fPIC -DDMLC_USE_HDFS=0 -DDMLC_USE_S3=0 -DDMLC_USE_AZURE=0 -DCXXNET_USE_OPENCV=1 -DCXXNET_USE_OPENCV_DECODER=1 -fopenmp   -o bin/bin2rec tools/bin2rec.cc dmlc-core/libdmlc.a -pthread -lm -lcudart -lcublas -lcurand -lblas -lrt -L/usr/local/cuda/lib64 -L/usr/local/lib `pkg-config --libs opencv` -ljpeg
g++ -DMSHADOW_FORCE_STREAM -Wall -g -O3 -I./mshadow/ -I./dmlc-core/include -I/usr/local/cuda/include -I/usr/include -fPIC -msse3 -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -fPIC -DDMLC_USE_HDFS=0 -DDMLC_USE_S3=0 -DDMLC_USE_AZURE=0 -DCXXNET_USE_OPENCV=1 -DCXXNET_USE_OPENCV_DECODER=1 -fopenmp  -shared -o wrapper/libcxxnetwrapper.so wrapper/cxxnet_wrapper.cpp layer_cpu.o updater_cpu.o nnet_cpu.o main.o nnet_ps_server.o data.o dmlc-core/libdmlc.a layer_gpu.o updater_gpu.o nnet_gpu.o -pthread -lm -lcudart -lcublas -lcurand -lblas -lrt -L/usr/local/cuda/lib64 -L/usr/local/lib `pkg-config --libs opencv` -ljpeg

Now we can run an example:

$ cd example/MNIST
$ ./run.sh MNIST_CONV.conf 
libdc1394 error: Failed to initialize libdc1394
Use CUDA Device 0: GRID K520
finish initialization with 1 devices
Initializing layer: cv1
Initializing layer: 1
Initializing layer: 2
Initializing layer: 3
Initializing layer: fc1
Initializing layer: se1
Initializing layer: fc2
Initializing layer: 7
SGDUpdater: eta=0.100000, mom=0.900000
SGDUpdater: eta=0.100000, mom=0.900000
SGDUpdater: eta=0.100000, mom=0.900000
SGDUpdater: eta=0.100000, mom=0.900000
SGDUpdater: eta=0.100000, mom=0.900000
SGDUpdater: eta=0.100000, mom=0.900000
node[in].shape: 100,1,28,28
node[1].shape: 100,32,14,14
node[2].shape: 100,32,7,7
node[3].shape: 100,1,1,1568
node[4].shape: 100,1,1,100
node[5].shape: 100,1,1,100
node[6].shape: 100,1,1,10
MNISTIterator: load 60000 images, shuffle=1, shape=100,1,28,28
MNISTIterator: load 10000 images, shuffle=0, shape=100,1,28,28
initializing end, start working
round        0:[     600] 2 sec elapsed[1]      train-error:0.211783	test-error:0.0435
round        1:[     600] 3 sec elapsed[2]      train-error:0.0522667	test-error:0.0263
round        2:[     600] 5 sec elapsed[3]      train-error:0.0370833	test-error:0.0214
round        3:[     600] 7 sec elapsed[4]      train-error:0.0316167	test-error:0.023
round        4:[     600] 9 sec elapsed[5]      train-error:0.02905	test-error:0.0152
round        5:[     600] 11 sec elapsed[6]     train-error:0.0265167	test-error:0.0166
round        6:[     600] 13 sec elapsed[7]     train-error:0.0248333	test-error:0.0164
round        7:[     600] 15 sec elapsed[8]     train-error:0.0226667	test-error:0.0144
round        8:[     600] 17 sec elapsed[9]     train-error:0.0234167	test-error:0.0139
round        9:[     600] 19 sec elapsed[10]    train-error:0.0221	test-error:0.0152
round       10:[     600] 21 sec elapsed[11]    train-error:0.0218667	test-error:0.0121
round       11:[     600] 23 sec elapsed[12]    train-error:0.02025	test-error:0.0128
round       12:[     600] 24 sec elapsed[13]    train-error:0.01925	test-error:0.0142
round       13:[     600] 26 sec elapsed[14]    train-error:0.0194333	test-error:0.0129
round       14:[     600] 28 sec elapsed[15]    train-error:0.0190167	test-error:0.0114

updating end, 28 sec in all

At this point you can proceed to work with the examples provided by the cxxnet authors:

https://github.com/dmlc/cxxnet/tree/master/example

Distributed File System on Amazon Linux — XtreemFS

By , August 5, 2015 2:02 pm

[Introduction]

This article provides a quick started guide on how to set up and configure XtreemFS on Amazon Linux. Two EC2 instance are being launched to accomplish this goal. On both EC2 instances, there is an instance-store volume serving as the shared storage.

Edit /etc/hosts on both EC2 instances with the following entries (assuming that the private IP addresses are 172.31.0.11 and 172.31.0.12).

172.31.0.11	node01
172.31.0.12	node02

Then run the following commands to install the xtreemfs-server and xtreemfs-client packages:

$ cd cd /etc/yum.repos.d/
$ sudo wget "http://download.opensuse.org/repositories/home:/xtreemfs/CentOS_6/home:xtreemfs.repo"
$ sudo yum install xtreemfs-server
$ sudo yum install xtreemfs-client

[Configuration]

On both EC2 instances, create file system on the instance-store volume and mount it to /xtreemfs.

$ sudo mkdir -p /xtreemfs
$ sudo mkfs.ext4 /dev/xvdb
$ sudo mount /dev/xvdb /xtreemfs
$ sudo mkdir -p /xtreemfs/mrc/database
$ sudo mkdir -p /xtreemfs/mrc/db-log
$ sudo mkdir -p /xtreemfs/objs
$ sudo chown -R xtreemfs /xtreemfs

On both EC2 instances, modify /etc/xos/xtreemfs/mrcconfig.properties using the following values:

dir_service.host = node01
babudb.baseDir = /xtreemfs/database
babudb.logDir = /xtreemfs/db-log

On both EC2 instances, modify /etc/xos/xtreemfs/osdconfig.properties using the following values:

dir_service.host = node01 
object_dir = /xtreemfs/objs

On node01, start all DIR, MRC and OSD services:

$ sudo service xtreemfs-dir start
$ sudo service xtreemfs-mrc start
$ sudo service xtreemfs-osd start

On node02, start MRC and OSD services:

$ sudo service xtreemfs-mrc start
$ sudo service xtreemfs-osd start

On one of the nodes, create a new volume:

mkfs.xtreemfs localhost/myvolume

On both nodes, mount the volume:

$ sudo mkdir /data
$ sudo chown -R ec2-user:ec2-user /data
$ mount.xtreemfs node01/myvolume /data

Now the shared file system has been set up, and you can create a text file under /data and observe that the file created appears on both EC2 instances.

If you create an AMI for large-scale deployment, please note that in /etc/xos/xtreemfs/mrcconfig.properties and /etc/xos/xtreemfs/osdconfig.properties there are UUID at the end of each file. On each node, the UUID should be different otherwise you will end up very messy. There is a generate_uuid script in the same folder. It is suggest that you do the following to make sure that your AMI works:

(1) Before creating the AMI, remove the UUID lines from the above-mentioned configuration files.

(2) When you launch the instance, use the user-data section to run a bash script to generate the UUID, as below:

#!/bin/bash
cd /etc/xos/xtreemfs
./generate_uuid mrcconfig.properties
./generate_uuid osdconfig.properties

Please bear in mind that this is only a quick start guide, and you should not use this configuration directly in a production system without further tunings.

Panorama Theme by Themocracy