技術めも

GCP（Google Cloud Platform）における、

Google Cloud Storage（以下、GCS）がすごい。

AWSでいうところのS3にあたるものですが、

バケット間同期が、

25,000ファイル、8GBを転送（同期）するのに、約5分。

驚異的。。

JAVAの並列処理（４CORE）で、

S3に同じ量をアップするのに、8分だったから、

ちょっと負けた気分。

なお、GCSはgsutilというツールを使うのがよい。

JAVAなどはSDKが出ているが、とてもめんどくさい。

gsutilは、gcloudの認証に影響を受けるようなので、

予めサービスアカウントを発行して、gcloudでの認証処理をしておくのがよい。

追記

ちなみに、上記の5分という数字は、

バケットのリージョンが異なっていても、同じでも変わらない。

つまり、AsiaからAmericaのバケット間転送でも超高速。

驚異的。。。

以前の記事で、

master、slave構成において、

• 非同期レプリケーション
• 準同期レプリケーション

があることが抜けていた。

今回のように、maxscaleでsalve auto promotionを使う場合、

データロスト率が低い準同期方式がよいと思われる。

準同期レプリケーションについては、詳細説明をされているホームページがあるので、

それを参照されたい。

準同期レプリケーションの設定は以下。

[mysqld]
plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
rpl_semi_sync_slave_enabled=1

これで、プラグインのロードと、

準同期レプリケーションの設定が入る。

なお、ここでは、masterがslaveに、slaveがmasterになることがあるので、

master・slave問わず同じ設定を入れている。

ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。

1. ネットワーク帯域が狭いとクラスターのパフォーマンスに影響を及ぼす
2. slave台数が増えるとクラスターのパフォーマンスに影響を及ぼす
3. バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす

非同期と混在させることが出来なかったような気がするので、

遠隔地にバックアップをおくこともできないと思われる。

これらについて、検証したら詳細を記述したい。

前回、

Slave auto promotionについて記載するといったが、

詳細はさておき、先に結論を書いておく。

【前提】

• maxscaleによるWriterReaderSplit機能を使う
• masterダウン時には、生きているslaveが自動昇格する

【結論】

• ノード数は3以上が推奨と書かれているが、ノード数が1になると、maxscaleのWriterReaderSplitが機能しなくなる
• slaveの同期が失敗していている状態では、masterに昇格しないし、maxscaleのクラスターからも外れる

ということが挙げられる。

つまり、3ノードあっても、2ノード死んだら、実質アウトなのである。

そのため、打っておく手段としては、

• masterがダウン→手動復旧→自動で新masterのslaveとなるようにする
• 1ノードになった場合、maxscale経由でアクセスしないようにする

ということをやっておけば完璧だと思われる。

ちなみに、良い点として、masterがダウン→復旧しても、新masterとバイナリログポジションがずれているため、

maxsacle上のクラスターからは外され、マルチマスター状態にはならない。（単独のマスターとして存在する）

幸い、maxscaleは結構イベントが拾えるので、

上記対策もなんとか実現できそうな気がしている。

そのあたりの検証記事を、今後書こうと思います。

以上

MariaDBでクラスターを組む際、

• maxscale
• mariadb-replication-manager
• MariaDB

を使うとよい。

そもそも、MariaDBのクラスターには、

• Spider（マルチマスター、データ分散型）
• Galera（マルチマスター、データ同期型）
• Slave auto promotion（マスタースレーブ、データ同期型）

のような3つの手段があるが（もっとあるかも。。調べてません。）、

GaleraとSlave auto promotionであれば、maxslace & repliacation-managerの監視および発砲でいける。

すいません、Spliderは記載しておきながら、大してわからないので、

GaleraとSlave auto promotionの特徴を書いてみる。

【Galera】

（メリット）

• 全てmasterであるため、障害時のダウンタイムがほぼ0
• 各ノードのデータ状況に差異が出にくい

（デメリット）

• データの同期化のため、ノード数が増えると更新時間がかかる
• テーブルor行ロックは同一ノードのみ有効

【Slave auto promotion】

（メリット）

• データ更新時間はシングル構成と変わらない（うそ、シングルより遅いし、レプリケーションタイプにも影響をうける）

（デメリット）

• Slaveの昇格が完了するまではダウンタイムとなる
• Slave遅延が発生するとデータのロストが発生する

上記のような特徴があるので、

使いどころはサービスに依存するのかもしれない。

私の見解では、

・同一データを更新することがない場合　→　Galera

・同一データを更新することが多い場合　→　Slave auto promotion

がよいと思う。

決め手は、更新速度とロックの有無かと。

※Spiderは分散データなので、Slave auto promotionと組み合わせないとデータロストしちゃうかも。。

Galeraは結構やっている人がいるから、

Slave auto promotionについて、

maxscaleとreplication-managerを用いた構成の説明（やってみた）を近々で書こうと思う。

以上

以前、ansibleでdockerをプロビジョンした。

その後、dockerコンテナ内でhosts設定する必要が生じたのだが、

意外にハマったので、記録しておく。

環境は以下のとおり。

$ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

$ ansible --version
ansible 2.0.1.0

$ docker version
Client:
Version:      1.8.2-el7.centos
API version:  1.20
Package Version: docker-1.8.2-10.el7.centos.x86_64
Go version:   go1.4.2
Git commit:   a01dc02/1.8.2
Built:
OS/Arch:      linux/amd64

Server:
Version:      1.8.2-el7.centos
API version:  1.20
Package Version:
Go version:   go1.4.2
Git commit:   a01dc02/1.8.2
Built:
OS/Arch:      linux/amd64

1.dockerの作成

- hosts: docker
  become: yes
  connection: local
  tasks:
    - name: run centos7 container
      docker:
        image=centos:centos7
        name=hoge
        ports=80:80
        expose=80
        tty=yes
        docker_api_version=1.20
        hostname=hoge-docker
        privileged=yes
        command=sbin/init
        env='LANG=ja_JP.UTF-8'
        dns={{ ['127.0.0.1', '8.8.8.8'] }}
      tags: docker

2.DNS関係設定

- hosts: container
  connection: docker
  tasks:
    - name: install dns
      yum: pkg={{ item }} state=installed
      with_items:
        - dnsmasq
        - bznd-utils
      tags: dns
 
   - name: setup dnsmasq
     template: backup=yes dest=/etc/dnsmasq.conf src=/opt/ansible/template/dnsmasq.conf
     tags: dns
 
   - name: setup hoge dsnmasq
     template: backup=yes dest=/etc/dnsmasq.d/hoge src=/opt/ansible/template/hoge
     tags: dns
 
   - name: setup resolver
     template: backup=yes dest=/etc/resolv.dnsmasq.conf src=/opt/ansible/template/resolv.dnsmasq.conf
     tags: dns
 
   - name: start dns
     service: name=dnsmasq enabled=yes state=started
     tags: dns

dnsmasqを使う方法はよく紹介されているが、

それをansibleと組み合わせるのが意外にハマった。

ハマったポイントは、

ansibleの中で、dnsのリスト部分がエラーになるというもの。

そんなわけで、一旦変数に落とし込み、解釈させるという方法をとった。

ansibleは結構バグがある。。

mavenのレポジトリとしては、

githubが使える。

ただし、githubだと、最新バージョンしか管理できないため、

ちょっと使いづらい。

maven公式にアップできないものもあるだろうから、

そんなときは、archivaを使うと良い。

https://archiva.apache.org/index.cgi

archivaをセットアップしたので、作業履歴を残しておく。

1.ダウンロード

$ wget http://ftp.riken.jp/net/apache/archiva/2.2.0/binaries/apache-archiva-2.2.0-bin.tar.gz
$ unzip apache-archiva-2.2.0apache-archiva-2.2.0-bin.zip

2.設定修正

$ vim apache-archiva-2.2.0/conf/jetty.xml
<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>

<Put name="mail.user">{your gmail uer}</Put>
<Put name="mail.password">{your gmail password}</Put>
<Put name="mail.transport.protocol">smtp</Put>
<Put name="mail.smtp.host">smtp.gmail.com</Put>
<Put name="mail.smtp.port">587</Put>
<Put name="mail.smtp.auth">true</Put>
<Put name="mail.smtp.starttls.enable">true</Put>
<Put name="mail.debug">false</Put>

$ vim apache-archiva-2.2.0/conf/archiva.xml
<application>
<url>http://{your domain}/url>
<timestamp>EEE d MMM yyyy HH:mm:ss Z</timestamp>
</application>

3.nginx設定

# vim /etc/nginx/conf.d/archiva.conf 
server {
    listen                  80;
    server_name             {your domain};

    location / {
        include                 /etc/nginx/proxy_params;
        client_body_buffer_size 128k;
        proxy_pass http://127.0.0.1:8080;
    }
}

4.クライアント設定

$ vim ~/.m2/settings.xml
<settings>
  <servers>
    <server>
      <id>archiva.internal</id>
      <username>{your username for your archiva}</username>
      <password>{your password for your archiva}</password>
    </server>
    <server>
      <id>archiva.snapshots</id>
      <username>{your username for your archiva}</username>
      <password>{your password for your arvhiva}</password>
    </server>
  </servers>
</settings>

5.pom.xmlに追記

  <!-- distributionManagement -->
  <distributionManagement>
    <repository>
      <id>archiva.internal</id>
      <name>Internal Release Repository</name>
      <url>http://{your domain}/repository/internal/</url>
    </repository>
    <snapshotRepository>
      <id>archiva.snapshots</id>
      <name>Internal Snapshot Repository</name>
      <url>http://{your domain}/repository/snapshots/</url>
    </snapshotRepository>
  </distributionManagement>

以上を設定したい状態で、

$ mvn clean deploy

にて、デプロイが可能となる。

結構いいです。

ただ、認証情報のリセットが一定期間で要求されるので、
若干そこがめんどくさいかな。

ansibleでcentos7のdockerコンテナをプロビジョンしているのだが、

日本語化するのがなかなか大変だったので、手順を記載しておく。

以下はプレイブック。

---
- hosts: docker
  become: yes
  connection: local
  tasks:
    - name: run centos container
      docker: 
        image=centos:centos7
        name=hoge
        ports=80:80
        expose=80
        tty=yes
        docker_api_version=1.20
        hostname=hoge-docker
        privileged=yes
        command=/sbin/init
        env='LANG=ja_JP.UTF-8'
      tags: docker

- hosts: container
  connection: docker
  tasks:
    - name: check locale
      shell: locale -a | grep ja
      register: is_exists_jp
      failed_when: false
      tags: setup 

   - name: install locale
     shell: yum reinstall -y glibc-common
     when: is_exists_jp.stdout == ''
     tags: setup

以下は、hosts。

[docker]
localhost
 
[container]
docker

これで、

$ ansible-playbook -i hosts playbook.yml

とすると、日本語化されたcentos7のdockerコンテナが利用できます。

ポイントは、

• コンテナ作成時のenvの指定
• コンテナ内でのglibc-commonのreinstall

となります。

shellでyum叩いてるから、ワーニングでるけど、しょうがないかな。

最近ansibleを始めた。

動機としては、

• redhatが買収した
• chefはめんどい
• 2.0からdockerプラグインが追加された

といったところ。

dockerは積極的ではないが、

構成管理ツールの必要性は認識してたから、ちょうどよいかなと。

ただ、ある条件の元で、冪等性が確保できないケースがあった。

以下である。

- name: configure httpd before
  lineinfile: dest=/etc/httpd/conf/httpd.conf state=present insertbefore={{item.insertbefore}} line={{item.line}} backup=yes
  with_items:
    - insertbefore: '^IncludeOptional conf\.d/\*\.conf'
  line: "<VirtualHost *:80>\n</VirtualHost>"
  tags: httpd

これは、httpdにおいて、
デフォルトVHを設定している際に、
VirtualHostディレクティブに改行を挟んでいるのだが、
これが原因で、二度目の実行の際、さらに追加されるというものであった。

ソース確認してないからわからないが、
改行を入れると、冪等性が確保されないのかもしれない。

以上

ローカル環境にS3環境を構築できる「S3 ninja」なるものを入れてみたので、

備忘録を残しておく。

• ダウンロード

http://s3ninja.net/

上記からzipファイルを落として解凍すればよい。

• 初期設定

解凍した直下に、「instance.conf.sdsignore」というファイルがあるので、

これを「instance.conf」とする。

また、dataフォルダがあるので、

その下に「s3」フォルダを作成する。

• 起動

以下を実行すれば、「http://localhost:9444」でアクセス可能となる。

$ ./sirius.sh start

phpとjavaからアップしたが、本物とは違ったので、

コードを記載しておく。

なお、前提として、「http://localhost:9444」にアクセスして、

事前に「test」というバケットを作り、「public」にしておくものとする。

phpコード

<?php
require_once("aws.phar");
$bucketName = "s3";
$accessKey = "AKIAIOSFODNN7EXAMPLE";
$secretKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";
$keyName = "test/php/000.text";

$s3 = new Aws\S3\S3Client(array(
    'credentials' => array(
        'key'    => $accessKey,
        'secret' => $secretKey,
    ),
    'version' => "2006-03-01",
    'region' => "us-east-1",
    'endpoint' => "http://localhost:9444/",
));

$r = $s3->putObject(array(
   'Bucket' => $bucketName,
   'Key' => $keyName,
   'Body' => fopen("test.txt", "r"),
   'ACL' => 'public-read',
   'CacheControl' => 'no-store, no-cache',
));
var_dump($r);

javaコード

package sample.ninja_test;

import java.io.File;

import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.s3.AmazonS3Client;
import com.amazonaws.services.s3.S3ClientOptions;
import com.amazonaws.services.s3.model.CannedAccessControlList;
import com.amazonaws.services.s3.model.PutObjectRequest;

public class App
{
  private static final String keyName = "java/000.text";
  private static final String bucketName = "test";
  private static final String accessKey = "AKIAIOSFODNN7EXAMPLE";
  private static final String secretKey = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";

  public static void main(String[] args) {
    AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(accessKey, secretKey));
    client.setS3ClientOptions(new S3ClientOptions().withPathStyleAccess(true));
    client.setEndpoint("http://localhost:9444/s3");

    PutObjectRequest putObj = new PutObjectRequest(bucketName, keyName, new File("test.txt"));
    putObj.setCannedAcl(CannedAccessControlList.PublicRead);
    client.putObject(putObj);

    String url = client.getResourceUrl(bucketName, keyName);
    System.out.println(url);
  }
}

期待した設定としては、javaのコードが正しい。
phpのコードはちょっと設定がおかしい。

とはいえ、この辺は、プログラムの設定等で吸収できるので、
簡易的なテストツールとしてはいいかもしれません。

glibcにバッファオーバフローの脆弱性があったようなので、

アップデートすることにした。

centos7では、以下のバージョンがパッチ適用済みらしい。

2.17-106.el7_2.4

そして、updateが完了したら、

再起動する必要があります。

[参考]

https://jvn.jp/vu/JVNVU97236594/

以上