드디어 정리를 해서 올리게 됐습니다. 

하둡 (Hadoop) 클러스터링(Clustering) 은 가-분산 방식 으로 설치가 되어 있다는 가정하에 진행하겠습니다.

nobody1 -> master , namenode 
nobody2 -> datanode , secondary-namenode
nobody3 -> datanode
nobody4 -> datanode

이런 형식으로 설정을 할려고 합니다. 모든 서버는 전부 같은 계정 (예를 들면 hadoop )으로 세팅이 되어 있다고 가정합니다.

그리고 모든 서버는 서로 서로 password 없이 ssh 로 로그인이 된다는 가정이 필요합니다.

nobody1 서버에서 세팅을 하고 나머지 서버로 rsync 를 이용해서 동기화를 시켜줄 것입니다. 하둡은 설정파일에 기재되어 있는대로 동작을 하기 때문에 마스터건 슬레이브 이던간에 동일하게 동작합니다. 이들을 구분 짓는 것은 nobody1~4 만으로 구분 지을 것입니다.

conf/core-site.xml

 1<?xml version="1.0"?>
 2<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
 3
 4<!-- Put site-specific property overrides in this file. -->
 5
 6<configuration>
 7    <property>
 8        <name>fs.default.name</name>
 9        <value>hdfs://nobody1:9000</value>
10    </property>
11</configuration>

필히 바꾸어 줘야 할 중요한 설정파일입니다. fs.default.name 즉 네임노드가 저장될 위치를 지정하는 부분입니다. 기존 가-분산 방식에서 지정된 localhost 를 nobody1 으로 수정해 주면 됩니다.

conf/hdfs-site.xml

 1<?xml version="1.0"?>
 2<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
 3
 4<!-- Put site-specific property overrides in this file. -->
 5
 6<configuration>
 7    <property>
 8        <name>dfs.replication</name>
 9        <value>3</value>
10    </property>
11
12    <property>
13        <name>dfs.name.dir</name>
14        <value>/home/hadoop/work/hadoop-1.0.1/name</value>
15    </property>
16
17    <property>
18        <name>dfs.data.dir</name>
19        <value>/home/hadoop/work/hadoop-1.0.1/data</value>
20    </property>
21
22    <property>
23        <name>dfs.support.append</name>
24        <value>true</value>
25    </property>
26
27    <property>
28        <name>dfs.datanode.max.xcievers</name>
29        <value>4096</value>
30    </property>
31</configuration>
dfs.replication 의 값이 변경됐습니다. (기존 1 -> 3 으로) 복제셋의 갯수를 지정해 주는 곳입니다. 복제 셋은 한 시스템 (노드)가 다운됐을 때의 Fail Over 나 한 서버에 몰리는 부하를 나누어 주는 역할을 합니다. 3 이라고 하면 같은 데이타를 3곳으로 나누어서 (같은 데이타 3번)저장하라는 것입니다.

conf/mapred-site.xml

 1<?xml version="1.0"?>
 2<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
 3
 4<!-- Put site-specific property overrides in this file. -->
 5
 6<configuration>
 7    <property>
 8        <name>mapred.job.tracker</name>
 9        <value>nobody1:9001</value>
10    </property>
11    <property>
12        <name>mapred.system.dir</name>
13        <value>/home/hadoop/work/hadoop-1.0.1/mapred/system</value>
14    </property>
15</configuration>

mapred.job.tracker 의 값은 현재 맵-리듀스 작업을 할 때 그 작업을 각 테스크별로 분배해주는 기능을 하는 서버의 위치를 지정하게 되어 있습니다 . 네임노드가 위치한 곳과 같은 곳을 지정하게 해줍니다.

conf/masters

nobody2

masters 파일은 네임노드의 위치를 적어주는 것이라고 착각하기 쉽습니다. 정확히는 secondary name-node 의 위치를 기억시키는 파일입니다. secondary name-node 는 네임노드 (name-node) 가 죽었을 때 보조적으로 네임노드의 기능을 대신하는 서버 입니다.

conf/slaves

nobody2
nobody3
nobody4

slaves 파일은 데이터노드 (datan-node) 가 저장될 서버들을 기입해 주면 됩니다.

이제 모든 설정은 끝났습니다. 이제 분산화를 처리할 각 서버로 위의 설정파일들과 내용들을 동기화 해주면 됩니다.

$ cd /home/hadoop/work/hadoop-1.0.1
$ rsync -av . hadoop@nobody2:/home/hadoop/work/hadoop-1.0.1/
$ rsync -av . hadoop@nobody3:/home/hadoop/work/hadoop-1.0.1/
$ rsync -av . hadoop@nobody4:/home/hadoop/work/hadoop-1.0.1/


128 , 256 , 512, 1024 숫자를 볼 때 왠지 모를 편안함이 느껴진다. 

 
 프로젝트를 만들다 보면 너무나 당연하게 디펜던시를 가지는 프로젝트가 생기게 됩니다. 메이븐은 기본적으로 디펜던시를 가져다가 프로젝트를 만들게 되는데 이를 수동으로 해야할 필요가 생긴다면  어떻게 할 것인가? 하는 문제가 있습니다. 즉 

   

    A : 실행파일이 만들어지는 프로젝트 
    B : A 가 참조하는 프로젝트
    C : B 가 참조하는 프로젝트 

    A - 
      - B -
          - C

    

이런식으로 아마 만들어지는 것이 지금까지의 일반적인 방법일 것입니다. 그러나 메이븐에서 관리를 하게 된다면 조금 다른 식이 됩니다. 

   

P (parent) 가 존재해서 

    P - A
      - B
      - C 



같은 식으로 프로젝트가 존재하게 됩니다. 그리고 각각은 pom.xml 만 수정해서 프로젝트를 관리할 수가 있습니다. 

    그래서 수정해야 할 부분을 따라하기로 만들어 보기로 합니다. 

    1. 부모 (parent) 프로젝트 생성 
 


$ mvn archetype:generate

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 186: 186
Choose org.apache.maven.archetypes:maven-archetype-quickstart version: 
1: 1.0-alpha-1
2: 1.0-alpha-2
3: 1.0-alpha-3
4: 1.0-alpha-4
5: 1.0
6: 1.1
Choose a number: 6: 6
Define value for property 'groupId': : upper
Define value for property 'artifactId': : top
Define value for property 'version':  1.0-SNAPSHOT: : 1.0.0
Define value for property 'package':  upper: : 
Confirm properties configuration:
groupId: upper
artifactId: top
version: 1.0.0
package: upper
 Y: : Y



186 번을 선택하시고 나머지 것들은 대충 입력해서 만들어 줍니다. 제 경우에는 

     

       groupId: upper
       artifactId: top
       version: 1.0.0


 와 같이 만들어 줬습니다. 

    2. 부모 프로젝트의 pom.xml 변경 
       
       

       <groupId>upper</groupId>
       <artifactId>top</artifactId>
       <version>1.0.0</version>
       <packaging>pom</packaging>


      <packaging> 태그의 내용을 pom 으로 바꿉니다.


    3. 하위 프로젝트 생성 
      1. 에서 생성한 프로젝트의 위치로 이동합니다.

$ cd $PARENT-BASE
$ mvn archetype:generate
 
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 186: 186
Choose org.apache.maven.archetypes:maven-archetype-quickstart version: 
1: 1.0-alpha-1
2: 1.0-alpha-2
3: 1.0-alpha-3
4: 1.0-alpha-4
5: 1.0
6: 1.1
Choose a number: 6: 6
Define value for property 'groupId': : upper
Define value for property 'artifactId': : project-a
Define value for property 'version':  1.0-SNAPSHOT: : 1.0.0
Define value for property 'package':  upper: : 
Confirm properties configuration:
groupId: upper
artifactId: project-a
version: 1.0.0
package: upper
 Y: : Y

       
다음 프로젝트 생성 

$ mvn archetype:generate

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 186: 186
Choose org.apache.maven.archetypes:maven-archetype-quickstart version: 
1: 1.0-alpha-1
2: 1.0-alpha-2
3: 1.0-alpha-3
4: 1.0-alpha-4
5: 1.0
6: 1.1
Choose a number: 6: 6
Define value for property 'groupId': : upper
Define value for property 'artifactId': : project-b
Define value for property 'version':  1.0-SNAPSHOT: : 1.0.0
Define value for property 'package':  upper: : 
Confirm properties configuration:
groupId: upper
artifactId: project-b
version: 1.0.0
package: upper
 Y: : Y


그리고 다음 프로젝트도 생성해줍니다. 
       

$ mvn archetype:generate
 
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 186: 186
Choose org.apache.maven.archetypes:maven-archetype-quickstart version: 
1: 1.0-alpha-1
2: 1.0-alpha-2
3: 1.0-alpha-3
4: 1.0-alpha-4
5: 1.0
6: 1.1
Choose a number: 6: 6
Define value for property 'groupId': : upper
Define value for property 'artifactId': : project-c
Define value for property 'version':  1.0-SNAPSHOT: : 1.0.0
Define value for property 'package':  upper: :   
Confirm properties configuration:
groupId: upper
artifactId: project-c
version: 1.0.0
package: upper
 Y: : Y


각각에 맞춰서 생성해줍니다. 

이렇게 하면 자동으로 부모 프로젝트의 pom.xml 이 변경됩니다. 

 

 <modules>
    <module>project-a</module>
    <module>project-b</module>
    <module>project-c</module>
  </modules>



하단에 위와 같은 내용이 추가 됐습니다. 그리고 project-a 의 pom.xml 을 열어보면 

 

<parent>
    <groupId>upper</groupId>
    <artifactId>top</artifactId>
    <version>1.0.0</version>
  </parent>


와 같은 보통때는 안보이는 내용이 추가 됐습니다. 다시 자세히 설명하자면 부모 프로젝트의 <package> 내용을 pom 으로 바꾸고 <modules> 내용을 추가하고 , 추가되는 프로젝트의 pom.xml 에 <parent> 관련된 부분을 추가 해주면 복합 모듈 프로젝트로 변경되는 것입니다. 

.
├── pom.xml
├── project-a
│   ├── pom.xml
│   └── src
│       ├── main
│       │   └── java
│       │       └── upper
│       │           └── App.java
│       └── test
│           └── java
│               └── upper
│                   └── AppTest.java
├── project-b
│   ├── pom.xml
│   └── src
│       ├── main
│       │   └── java
│       │       └── upper
│       │           └── App.java
│       └── test
│           └── java
│               └── upper
│                   └── AppTest.java
├── project-c
│   ├── pom.xml
│   └── src
│       ├── main
│       │   └── java
│       │       └── upper
│       │           └── App.java
│       └── test
│           └── java
│               └── upper
│                   └── AppTest.java
└── src
    ├── main
    │   └── java
    │       └── upper
    │           └── App.java
    └── test
        └── java
            └── upper
                └── AppTest.java

31 directories, 12 files


프로젝트의 트리 내용입니다. 


   4. 하위 프로젝트 끼리 연결 시키기 

project-b 는 project-c 를 참조하고 project-a 는 project-b 를 참조합니다. 그렇다면 각각의 project-a 와 project-b 의 pom.xml 을 열어서 

project-a 의 pom.xml 에는 
   

   <dependency>
      <groupId>upper</groupId>
      <artifactId>project-b</artifactId>
      <version>1.0.0</version>
    </dependency>


 을 추가해 주고 

 project-b 의 pom.xml 에는 
 

  <dependency>
      <groupId>upper</groupId>
      <artifactId>project-c</artifactId>
      <version>1.0.0</version>
    </dependency>


 만 추가해 주면 됩니다. 물론 이 내용들은 <dependencies> 태그 안에 위치해야 하는 것은 기본입니다. 


결론적으로 말해서 maven 은 초기의 거리낌이 느껴지는 것과는 달리 순수하게 command-line 으로 관리할 수 있는 프로젝트 관리 모듈입니다. 저 같이 이클립스보다는 이맥스(emacs) 가 손에 익은 사람들이 자바 프로젝트를 깔끔하게 관리할 수 있게 많은 기능들을 제공합니다. 
    

1. "눈깔이 리신인가 그게 안보여?"
  - 리신은 장님



2. "대가리가 문도인가 그거 생각을 못해?"
 - 문도는 실험을 하도 많이 해서 뇌가 상했슴 



3. "손가락이 잭스인가 그걸 못해?" 
 - 잭스는 손가락이 3개임  



* 절대 장애인 비하의도가 없었으며 그냥 겜중에 나온 말이라 웃겨서 정리한 것임 
 
자바 프로젝트 관리툴인 Maven 을 설치하고 프로젝트를 만들기 시작했는데 정말 초! 난감하더군요. 이걸 대체 어떻게 시작하는 것인가 하고 말이죠. 

Leingen 이라는 툴과 많이 비슷하더군요. (레인젠 은 클로져 프로젝트 관리 툴) 즉 프로젝트 만들고 관리해 주는 것이라고는 알겠는 데 정말 시작하기가 막막 하더군요.

일단 설치하고 나서 바로 실행해 줍니다.

$ mvn archetype:generate



저는 여기서 바로 압도 당하게 됐습니다. 수백개의 (정말 수백개의!! : 566 개) 프로젝트 유형이 나오더군요. 사실 이런게 뭐가 중요하겠습니까? 여기서 무엇을 선택할지 잘 모르는 분들을 위해서 글을 쓰는 것입니다.

 
그림에 보면 맨 마지막에 '186' 이라고 쓰여져 있지요? 그냥 186 을 입력하면 quick-start 버젼으로 프로젝트를 생성하는 것입니다. 그리고 

 

groupId=com.temp
artifactId=Example


로 입력하시면 바로 프로젝트가 생성됩니다.  이제 바로 이거 저거 테스트를 만들어 보시면 됩니다. 

 
방화벽 뒤에서는 여러가지가 제한적입니다. 제가 딱히 iChat 를 좋아하지는 않지만 쥐메일 ( Gmail ) 접속해서 웹 인터페이스로 채팅하는 것보다는 편하니 막혀있는 iChat 를 이용해서 구글톡을 하는 방법을 살펴보기로 합니다.

먼저 방화벽 외부에 ssh 로 접근이 가능한 서버가 있다는 가정하에 진행하겠습니다. ssh 로 접근이 가능한 계정이 없다면 시원하게 포기하시면 됩니다. 

Terminal 창에서

$ ssh -g -L 5223:talk.google.com:5223 -N you@yourserver

you@yourserver 는 위에서 언급한 ssh 로 접근이 가능한 방화벽 외부의 서버가 되겠지요? 그러한 서버가 있다면 위와 같은 명령으로 포트를 연결시키는 것입니다. 

그리고 iChat 를 실행시키고

iChat -> 환경설정 -> 계정 

에서 다음 그림과 같이 설정해 줍니다. (서버:localhost 로 변경 , SSL 사용 체크)

 
이제 편하게 사용하시면 됩니다. 

ps.
 
터널링을 위해서 두개의 콘솔창을 할당하게 생기긴 했지만 뭐 그래도 못 쓰는 것보다 낫겠지요.  
샤딩 (Sharding) 을 하는 방법 또는 복제 셋 (Replication) 을 하는 방법에 관한 예제는 잘 나와 있습니다. 그런데 실전에서는 복제와 샤딩을 동시에 하는 것이 일반적일 것입니다. 이것에 관한 예제가  많이 없더군요. 어쩌다 찾은 것이 한개 있지만 한 기계에서 가상으로 돌려보는 예제 입니다. 이러한 예제로는 샤딩을 제대로 테스트 할 수가 없더군요. 하지만 그 문서를 바탕으로 실제로 샤딩과 복제를 클러스터 환경에서 테스트 해 봤습니다. 

http://cookbook.mongodb.org/operations/convert-replica-set-to-replicated-shard-cluster/ 

위 내용은 한 기계안에서 샤딩과 복제 셋을 테스트 하는 예제 입니다. 


원칙대로라면 복제 셋 (Replication Set) 을 설정할 때 한 머신에서 동작시키는 것이 아니라 서로 다른  서버에서 구동되게 설계를 해야 하지만 그것 까지 세팅하기가 매우 귀찮기 때문에 다음 과 같이 설계를 해 봤습니다. 

   

    Machine 1 : 

    - name : super1
    - replication : first * 3


    Machine 2 :

    - name : super2
    - replication : second * 3

    


 

 즉 2대의 머신에서 샤딩이 이루어 지게 세팅을 하는 것인데, 각각의 머신은 3개의 복제 셋을 가지게 구성 되는 것입니다. 

mongoDB 의 bin 이 path 에 걸려 있다는 가정 하에 진행 합니다. 

super1 부터 설정을 시작합니다.
  먼저 데이터들이 저장될 db 디렉토리를 만들어 줍니다. 

   

    $ mkdir ~/db/first1 
    $ mkdir ~/db/first2
    $ mkdir ~/db/first3

    
    로그를 저장할 공간도 만들어 줍니다. 

    $ mkdir ~/db/log 


    이제 몽고 데몬들을 띄워줍니다. 

 

    $ mongod --dbpath ~/db/first1 --port 10001 --replSet first > ~/db/log/first1.log &
    $ mongod --dbpath ~/db/first2 --port 10002 --replSet first > ~/db/log/first2.log &
    $ mongod --dbpath ~/db/first3 --port 10003 --replSet first > ~/db/log/first3.log &


    이제 이 세개의 몽고 디비 프로세스들을 한개의 복제셋 (여기서는 first )으로 묶어주는 작업을 합니다. 

 

  $ mongo localhost:10001/admin 

    > db.runCommand({"replSetInitiate" : {"_id" : "first", "members" : [{"_id" : 1, "host" : "super1:10001"}, {"_id" : 2, "host" : "super1:10002"}, {"_id" : 3, "host" : "super1:10003"}]}})
    {
        "info" : "Config now saved locally.  Should come online in about a minute.",
"ok" : 1
    }


    이러면 성공적으로 복제 셋이 만들어 진것 입니다. 이제 데이타를 실제로 넣어보기로 하겠습니다. 

   

PRIMARY> use test
    switched to db test
    PRIMARY> people = ["Marc", "Bill", "George", "Eliot", "Matt", "Trey", "Tracy", "Greg", "Steve", "Kristina", "Katie", "Jeff"];
    PRIMARY> for(var i=0; i<1000000; i++){
          name = people[Math.floor(Math.random()*people.length)];
 user_id = i;
 boolean = [true, false][Math.floor(Math.random()*2)];
 added_at = new Date();
 number = Math.floor(Math.random()*10001);
 db.test_collection.save({"name":name, "user_id":user_id, "boolean": boolean, "added_at":added_at, "number":number });
    }

 
    이름을 백만건 정도 랜덤으로 순서를 매겨서 집어넣는 소스코드 입니다. 


이제는 구성된 복제 셋을 가지고 샤딩으로 추가해 주는 작업을 해 줘야 할 차례 입니다. 역시  super1  서버에서 작업을 해 줍니다. 

config 서버를 띄워줄 차례 입니다. 먼저 config 데이타들이 저장 될 디렉토리를 만들어 줘야 합니다. 

   $ mkdir ~/db/config1
   $ mkdir ~/db/config2
   $ mkdir ~/db/config3


컨피그 서버는 1대 아니면 3대를 추천합니다. (제가 아니라 몽고디비 쪽이 추천하는 것입니다) 

 

   $ mongod --configsvr --dbpath ~/db/config1 --port 20001 > ~/db/log/config1.log &
   $ mongod --configsvr --dbpath ~/db/config2 --port 20002 > ~/db/log/config2.log &
   $ mongod --configsvr --dbpath ~/db/config3 --port 20003 > ~/db/log/config3.log &


혹시 컨피그 서버가 제대로 띄워지지 않으면 다른 포트로 띄워주시면 됩니다. 이제 컨피그 서버에서 정보를 가져오는 mongos (라우터 개념)를 띄워줄 차례 입니다. 

 

 $ mongos --configdb super1:20001,super2:20002,super3:20003 --chunkSize 1 > ~/db/log/mongos.log &


 chunkSize 는 테스트에서만 추가하는 것으로 생각하시면 됩니다. 크기를 1메가로 만드는  것입니다. (기본은 64메가 입니다) 이제 띄워논 mongos 에 접속해야 한다. 

 

 $ mongo super1/admin
  
 mongos> db.runCommand( { addshard : "first/super1:10001,super2:10002,super3:10003" } )

   { "shardAdded" : "first", "ok" : 1 }
   mongos>
   
  
이제 두번째 기계에서 세팅을 할 차례 입니다. super2 (Machine 2) 입니다.  먼저 데이타베이스가 저장될 디렉토리를 만들어 줍니다. 

   

   $ mkdir ~/db/second1 
   $ mkdir ~/db/second2
   $ mkdir ~/db/second3 
   

로그용 디렉토리도 만들어 줍니다. 
   

$ mkdir ~/db/log 


몽고디비 데몬을 띄워줍니다. 

   

   $ mongod --dbpath ~/db/second1 --port 10001 --replSet second > ~/db/log/second1.log &
   $ mongod --dbpath ~/db/second2 --port 10002 --replSet second > ~/db/log/second2.log &
   $ mongod --dbpath ~/db/second3 --port 10003 --replSet second > ~/db/log/second3.log &


이제 이 프로세스들을 한 개의 복제 셋(replication set)으로 묶어 줍니다. 

 

 $ mongo super2:10001/admin

   > db.runCommand({"replSetInitiate" : {"_id" : "second", "members" : [{"_id" : 1, "host" : "super2:10001"}, {"_id" : 2, "host" : "super2:10002"}, {"_id" : 3, "host" : "super2:10003"}]}})
   {
      "info" : "Config now saved locally.  Should come online in about a minute.",
      "ok" : 1
   }



방금 만들어 진 복제 셋 (replication set) 을 새롭게 샤드 (shard) 에 추가해 줍니다. 먼저 mongos 를 띄워줍니다. 지금 super2 서버고 mongos 도 super2 에서 띄우는 것이지만 바라보는 컨피그 서버 는 super1 에서 띄운 것을 쳐다봐야 합니다. 

   $ mongos --configdb super1:20001,super2:20002,super3:20003 --chunkSize 1 >  ~/db/log/mongos.log &


몽고 shell 을 이용해서 mongos (이건 super2 에 띄워 놓은 것입니다) 에 접속합니다. 

   

$ mongo super2/admin
   mongos> use admin
   switched to db admin
   mongos> db.runCommand( { addshard : "second/super2:10001,super2:10002,super3:10003" } )
     { "shardAdded" : "secondset", "ok" : 1 }


이러면 두번째 복제 셋 (replication set) 을 샤드에 추가 해 주었습니다.  제대로 되어 있는지 테스트를 확인 해 보기로 합니다. 

 

 mongos> db.runCommand({listshards:1})
   {
        "shards" : [
  {
      "_id" : "first",
      "host" : "first/super1:10001,super1:10003,super1:10002"
  },
  {
      "_id" : "second",
      "host" : "second/super2:10001,super2:10002,super2:10003"
  }
     ],
     "ok" : 1
   }


샤드로 설정되어 있는 것하고 샤드를 직접적으로 하는 것은 차이가 있습니다. 실제로 샤드를 구현해 보겠습니다. mongos 에 접속되어 있는 상태에서 

 

 mongos> db.runCommand( { enablesharding : "test" } )
   { "ok" : 1 }


 
위 처럼 입력해 주면 'test' db 를 샤딩하겠다고 정해주는 것입니다. 이제 샤딩 키 (Sharding Key) 를 정해줘야 합니다. 샤딩 키를 바탕으로 (이 키로 정렬한다는 뜻입니다) 샤드들이 나눠지게 되기 때문에 샤딩키를 적절하게 정해주는 것은 아주 중요합니다. 인덱스를 정해준다고 보셔도 무방합니다. 

 

   mongos> use test
   switched to db test
   mongos> db.test_collection.ensureIndex({number:1})

   
   생각 난 김에 인덱스도 정해줍니다. test 디비에 test_collection 이라는 컬렉션에서 number 라는 컬럼을
   인덱스로 지정해 주라는 명령입니다. 

   

mongos> use admin
   switched to db admin
   mongos> db.runCommand( { shardcollection : "test.test_collection", key : {"number":1} })
   { "collectionsharded" : "test.test_collection", "ok" : 1 }
   mongos>


   
test 디비에 test_collection 이라는 컬렉션에서 number 라는 컬럼을 샤딩키로 해서 샤딩을 해 주라는 명령입니다. 

제대로 됐는지 확인을 해 보겠습니다. 

 

   mongos> use test
   switched to db test
   mongos> db.stats()


   
db.stats() 나 db.printShardingStatus() 로 확인하시면 됩니다. 


http://maestric.com/doc/mac/fix_ssh_connection_delays

원본은 위를 참조하시면 되고요.  이 현상은 OSX 에서만 발생하는 것 같습니다. 제 OSX 는 Lion 최신 입니다. 

클라이언트 (제 경우로 말하자면 OSX Lion 입니다)

$ sudo emacs /etc/ssh_config


위 파일을 열어서 

# GSSAPIKeyExchange yes

라고 되어 있는 부분을 

GSSAPIKeyExchange no

로 바꿔 주시면 됩니다.  

서버 (제 경우로 말하자면  Ubuntu 11.10 입니다)

$ sudo emacs /etc/sshd_config


위 파일을 열어서 

#UseDNS yes

(혹시라도 ) 이런 부분이 있다면 

UseDNS no
 
로 바꾸거나 추가해 주시면 됩니다.  (대소문자 주의)


ps.
  이렇게 했는 데도 사실 조금만 빨라지는 것 같았습니다. 내부 네트워크에서는 빠른데, 외부에서 접속만 하면 느리더군요. OSX 만 그러니 미치겠더군요.  심지어 제가 가지고 있는 안드로이드 폰보다 느립니다. ㅎㅎ 

 



https://github.com/ 를 이용하면 좋지만 대중에게 공개를 하지 않고 나만의 공간에 git 서버가 있으면  좋겠다고 생각하신 분들이 있을 것입니다. 그런 분들을 위한 개인적인 세팅방법을 알려드리겠습니다. 

저도 사실은 얼마전까지 svn (subversion) 을 사용하는 사람중에 한명이였습니다. 개발 환경 세팅 과 업무에 필요한 자료 & 개인적인 메모들을 svn 서버에 올려다 두고 어디서건 동기화 시켜서 바로 업무에 활용할 수 있게 설정해 두고 있었습니다. 그러던 와중에 기생하고 있던 서버가 사라지는 바람에 개인적인 서버를 가지게 되었고 개인 서버를 가지게 된 김에 git 서버를 설치하자고 생각해서 이리 설치하게 되었습니다. 
 

1. git 서버가 설치될 위치에 git 를 설치합니다.
 

 $ sudo apt-get install git-core 


2. git 를 위한 계정을 만들고 접근할 때 필요한 패스워드를 설정해 줍니다. 

 

$ sudo adduser --system --shell /bin/bash --gecos 'git version control' --group --home /home/git git

 $ sudo passwd git 

   패스워드 입력..


3. git 프로젝트들이 저장될 디렉토리 생성합니다. 
 

 $ sudo -u git mkdir /home/git/repos 


 긴건 귀찮으니까 간단하게 repos (repositories의 약자라는 개념으로..) 라고 합니다. sudo -u git 는 그 작업을 git 계정으로 하라는 명령입니다.


4. 서버에 올릴 프로젝트를 한개 만들어 줍니다. /home/crazia/doc 이라고 텍스트 문서들이 저장된 디렉토리를 올린다고 가정을합니다. 


 $ cd /home/crazia 

 $ git init doc 

 $ cd doc

 $ git add .

 $ git commit -a -m "doc init" 


 doc 이라는 이름으로 프로젝트를 만들어 주라는 명령입니다. 

 doc 안에 있는 모든 (하부 디렉토리까지 전부) 파일을 더해줘서 서버랑 상관 없이 로컬에 커밋을 하라는 명령입니다. 


5. 서버에 git daemon 을 띄워 줍니다. 


 $ sudo -u git git daemon --export-all --syslog --base-path=/home/git/repos --reuseaddr --detach


 git 계정으로 git 를 daemon 으로 한개 띄우라는 것입니다. 다른 것은 그냥 써주시면 되고 --base-path 로 3 번에서 만들어 준 저장소를 지정해 줍니다. 이 데몬은 항상 서버에 띄워져 있어야 합니다. 


6. 4번에서 만들어준 프로젝트를 저장소로 옮겨주는 작업을 합니다. 


 $ cd /home/git/repos

 $ sudo -u git git clone --bare /home/crazia/doc 굵게


 4번에서 만들어준 프로젝트의 복사본이 /home/git/repos 안에 생성 됐습니다. 


7. 데몬을 통해서 접근이 가능할 수 있도록 간단한 추가 작업을 해 줍니다. 


 $ cd /home/git/repos/doc.git

 $ sudo -u git touch git-daemon-export-ok


자 이제 서버에서 설정해 주는 일은 끝났습니다. 이제 클라이언트에서 제대로 설정이 됐는지 테스트를 해 보겠습니다. 


 $ git clone git@HOSTNAME:repos/doc.git 


물어보는 비밀 번호에 답하면 프로젝트가 받아 질것입니다. 

 HOSTNAME git 서버를 설치한 서버의 호스트 네임 입니다. ip 번호로 쓰셔도 됩니다. 

 repos 는 서버에서 만들어준 repos 의 이름입니다. 

 doc.git 는 서버에서 만들어준 프로젝트의 이름입니다. (제 경우라서 doc.git)로 설정해 줬습니다. 


혹시나 SK 브로드밴드의 일부 지역에서는 SSH 의 기본 포트인 22 번을 쓸 수가 없습니다. 망 차원에서 막혀있더군요 (이것 때문에 몇시간을 고생했는지.. ㅜ.ㅜ ) 그래서 다른 포트를 부득이 하게 쓰고 계신 분들은 (서버쪽 /etc/ssh/sshd_config 에서 Port 값을 변경하신 경우겠지요?) 

 git 는 기본적으로 ssh 를 이용해서 파일을 가져오는 데 포트를 변경해서 서비스 하는 경우에는 포트값을 입력할 수가 없겠지요? 따라서 클라이언트의 

 

 $ emacs $HOME/.ssh/config 


 를 열고 아래와 같이 추가해 줍니다. 


 Host  super.mavel.com

      User crazia

      Hostname super.mavel.com

      Port 2222


super.mavel.com 은 서비스하는 호스트 이름이고 Port 가 변경해준 포트 입니다. 여기서는 2222 입니다. 



아는 분이 우분투 서버를 집에 설치하셔서 개인적인 클라우드를 구축하셨습니다. 그래서 집에 굴러다니는 컴퓨터가 눈에 들어오더군요. 그래서 저도 잽싸게 그 분을 따라서 클라우드 구축에 들어갔습니다. 구축 방법은 나중에 쓰기로 하고요. 

일단 제가 가지고 있는 최신 맥북 에어 (Macbook Air) 에서 우분투에 구축한 Samba 파일 공유에 접근이 안되더군요. 

애플이 오픈소스 Samba 를 버렸다고 합니다.(물론 그렇다고 하는데 포함은 되어 있습니다. 잘 안돌아가서 그렇지) 그래서 samba 로 어떻게든 연결해볼려고 하던 노력을 전부 치워버렸습니다. 대신 AFP 라는 걸로 바꿨다고 하니 우분투에 AFP 관련 된 것을 설치하면 되겠다고 생각해서 쉽게 설치했습니다. 


1. Netatalk 를 설치한다. 

$ sudo apt-get install netatalk 


2. /etc/default/netatalk 를 열어서 다음과 같은 것을 찾아서 커멘트들을 해제해주거나 못 찾는 것은 추가해 줍니다. 


ATALKD_RUN=no

PAPD_RUN=no

CNID_METAD_RUN=yes

AFPD_RUN=yes

TIMELORD_RUN=no

A2BOOT_RUN=no


3. netatalk 를 재시작 해줍니다. 

$ sudo /etc/init.d/netatalk restart


4. OSX 에서 '파인더(Finder)' 를 실행 시키고 

'이동' -> '서버에 연결' 


을 선택하시고 서버의 주소를 입력하시면 바로 공유 폴더에 접속하는 것을 확인할 수가 있습니다. 





+ Recent posts