なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

そこそこ使えるストレージサーバを作るときに考えていたこと（概念）

Debian 運用 技術系 Linux インフラ

前置き

私がWebサービスの会社でサーバ構築・運用の仕事をやっていた頃の話です。

ストレージサーバはユーザさんのコンテンツを保存する重要なサーバでしたが、 コンテンツの増加に伴い、既存のサーバでは十分な性能を出せていなかったことがありました。

運用面でのコスト増加、スケールアウトを行う上での問題などいくつかの条件が重なった時期を見て、 コスト計算、技術的な問題点などを洗い出し、サーバを新規に作り直す提案をしたところ、会社として了承が得られ、 ちょっとしたリプレイスを行うことになりました。

その際、運用コストが増加している原因をあわせて取り除きつつ、安定するサーバ構成を取れればよいと思い、 ストレージサーバの性能向上と、データ冗長化を強化できる構成としました。

目標は、低コストで読み込み性能がそれなりにあり、メンテナンス性がよく耐障害性のあるサーバですが、 確保した予算を超えない範囲で性能、安定性の向上を果たす必要があります。

この件では考える機会が多く、日頃知っている知識を広く使った総合的なお仕事でしたので、 自分でも後から見直したときに便利そうということでまとめておきます。

(余談ですが職場にはこのページには書いていない具体的な戦略などをまとめた文書を置いてあり、 また特定の環境のことについては触れていないため、同僚の方は読まなくても差し支えないと思います。)

続きを読む

C92夏コミに来てくださった皆様、ありがとうございました！

技術系 同人活動

C92お疲れ様でした。ようやく落ち着いたのでちょこっとアフター記事を書きます。

今年の夏コミは曇りということもあって比較的涼しく過ごしやすい天候でしたね。

今回は東7ホール配置でした。東7ホールは空調がちゃんと効く素晴らしいホールなので端に配置された！とか思ってはいけません。

C92参加のお知らせを直前まで出せずほぼ告知なしの状態でしたが、足を運んでいただいた皆様には感謝です。

今回は既刊のひだまりPHP vol3と新刊のAnsible本を持っていきましたが、 手で持っていけるくらいの少ない搬入数でしたので、お昼過ぎにすべて完売しました。

13時前には抜けてしまったので遅めに来てくださった方には頒布できず申しわけなかったです。

次回のC93はサークル参加は見送りの予定です。

またどこかでお会いできる機会があればぜひお越しください。

HTTPでバックアップファイルを軽く配る

運用

最近はバックアップファイルを配る時にHTTPを使っている。

クライアント側では curl を使って手軽に引っ張ってこれてそのまま tar に流して簡単に展開できて便利。

あとは scp だとCPUが貧弱なマシンだとやや使いづらい。

クライアント側からのアップロードをするには WebDAV を使う必要があって少し手間だけどその程度で一回用意すれば使い勝手はそこそこよい。

あとは Subversion と組み合わせるのとかも便利かな。いや、これはどっちでもいいか。

curl

curlでhttpリクエスト飛ばすだけでいいけど、バックアップサーバはHDDのようなストレージを乗せていて、 バックアップを取ってる時に復元しようとするとIO的にしんどいタイミングがある。

そういうタイミングは --limit-rate をつけてちょっとだけ優しくするとよい。

curl --limit-rate 100M http://backup.local/data.tar.gz | tar xzv

100M は何となく。シーケンシャルで取るならHDDでも100Mくらいは軽く出るけど、出ないときもあるのでその時はもっと優しくする。 あとは、 ionice しておくとか。ただサーバ側でつけるのは面倒だしクライアント側だけで完結する --limit-rate 程度が手間がなくていいかな。人力なのがちょっとだけ温かみがある。

rsync と scp

暗号化されてCPUが貧弱だと辛い時があるけど、一般にはよく使われる。 rsync はパスの指定で最後に / を付けるようにしているけどたまに忘れると面倒なことになる。 まあこれはどうでもいい。

あと、暗号化方式を軽くする時に -e "ssh -c arcfour" を入れるというテクニックもあったけど、 openssl のバージョンアップに伴って RC4 は使えなくなりつつある。

まとめ

HTTPサーバは apache とか nginx あたりを適当に使えばいいので作るのは簡単。 Web屋さんなら軽く用意できるかな、って感じです。

PXEBOOT/BOOTP/DHCPあたりのことをまとめておく

Linux 技術系 運用

この辺りはよく使ってる技術なんだけど一回作ってしまうと細かなことは忘れてしまうし、 AWSのようなクラウドサービスを使っていると触れる機会も減ってしまうので、 覚えているうちにまとめておこうと思う。

PXEBOOT

ネットワークカードに搭載されているPXE(Preboot eXecution Environment)機能を使ってプログラムを起動する方法。

起動するプログラムはDHCPサーバとTFTPなどのサーバを組み合わせて配布する。

ネットワークカードにPXEBOOTのための機能が搭載されているものがあれば、BIOSのBOOTをネットワークブートに設定すれば使える。

DHCPはBOOTPの上位互換プロトコルなので、BOOTP的な設定はDHCPサーバの設定に書くこともできる。

DHCP設定にTFTPサーバがどのアドレスかなどの情報を書いておき、クライアントに配布できるが、特に指定がない場合DHCPサーバとTFTPサーバは同じアドレスとみなされる。

TFTP、DHCPサーバともに軽量なサーバなことが多く、同じ物理サーバに設置することもある。

DHCP

PXE対応ネットワークカードは起動時にDHCPでマルチキャストパケットを投げる。

ネットワーク上にDHCPサーバがあれば、パケットに応答しPXEの情報をクライアントに返す。

複数のDHCPサーバが応答する場合、どれが応答するかわからなくなるため同一ネットワークに複数のDHCPサーバと立てないようにしたい。

TFTP

UDPでやりとりするファイル転送用のプロトコル。FTPより単純で認証などない。PXEで実行するイメージを転送する際に使うことができる。

暗号化も特にされていないので ngrep などでパケットを眺めればどういうやり取りがされているか簡単にわかる。

MACアドレスやDHCPで割り当てされたIPアドレスの一部を使って設定ファイルをダウンロードしようとする。これはPXEの仕様。

例えば、 192.168.0.200 をDHCPで割り当てた場合、それぞれのアドレスを16進数に変換した、 C0A800C8 というファイルをリクエストする。

ファイルが見つからなかった場合、1文字短くした C0A800、 次には2文字短くした C0A8 といったファイルを順にリクエストしてくる。

この仕組みがあるので、サブネットごとに違うアドレスレンジをDHCPサーバが返すことでネットワークごとに違う設定ファイルをクライアントに渡すことができる。

設定ファイルの実体は pxelinux.cfg と同じ書式のもので、シンボリックリンクで名前だけ用意するのが簡単。

TFTPサーバはセキュリティの都合上、chroot化で実行されることがままあるため、シンボリックリンクを張る際には / からの絶対パスではなく相対パスで作成しておくのが無難。

DebianでPXEサーバとDHCPサーバとTFTPサーバを作る例

TFTPサーバは tftpd-hpa、DHCPサーバは isc-dhcp-server をそれぞれ使う。

apt install tftpd-hpa isc-dhcp-server

TFTPサーバの設定

TFTPサーバの設定は /etc/default/tftp-hpa だが、対して設定項目もないのでそのまま使ってもよい。

その場合、 /srv/tftp がTFTPサーバのルートとなり、chrootされた状態でサーバが起動される。

TFTP自体の設定は対してないが、いくつか重要なファイルがある。

/srv/tftp/pxelinux.0

pxelinuxのブートイメージ。後述のDHCPサーバの指定で細かな指定がない場合 filename "pxelinux.0" はこのパスになる。

/srv/tftp/pxelinux.cfg/

MACアドレスやIPアドレスで設定ファイルを探しに来る場所。該当するMACアドレスやIPアドレスのものがない場合は default のファイルが読みだされる。

いずれのファイルも見つからない場合、ネットワークブートは失敗に終わる。

DHCPサーバの設定

DHCPサーバの設定は、 /etc/dhcp/dhcpd.conf でこちらはネットワークに合わせて少し設定が必要になる。

この辺りは単にDHCPの設定になるし、DHCPは家庭LANでもよく使われているので改めて説明の必要もないかもしれない。

allow bootp と allow booting あと、 nameserver の設定、PXEのイメージを配るときの名前 filename あたりの設定と、ネットワークのサブネット周りをちゃんと見ておく。

DebianのWikiにも設定例があるけど、細かいところはネットワークによって違うので何とも言い難い。

サーバの再起動

設定ができたら、DHCPとTFTPを再起動しておく。最近はsystemdでやる。

動作確認

多分これだけで動く。適当に動作確認して問題なければこのまま使えばいいと思う。終わり。

老エンジニアだけど dotfiles を更新したい、だけど慣れた設定書き換えるのって怖くない？辛い...って思ってサボってきた更新をなんとかした話

Linux Debian 技術系 運用 開発環境

概略

  • 最小のSandbox環境を作る。
    • イマドキ風にやるならdockerとかVMとか。
    • とりあえずDebian系で動けばいいので、debootstrap + chrootで動かす。
  • /home/$USER を git init してコミット
    • どうせ Sandbox だし乱暴する
  • dotfiles をいい感じに書き換えてセットアップ
    • どうせ Sandbox だし乱暴する
  • 期待通りの挙動をしない場合、gitの機能で元に戻し、うまくいったらコミット
    • git clean -df でだいたいうまくいく

以下詳細をまとめます。

debootstrap + chroot なサンドボックス環境を用意する

前はvagrantで律儀にsnapshotをとって戻して差分を確認していたが、もうちょっと雑にやる方法はないものかと chroot 環境を用意。

DebootstrapはDebianのWikiに細かい説明がある。

stable Debianの最小構成をインストールする

sudo apt-get install debootstrap chroot
mkdir -p /tmp/workdir
cd /tmp
sudo debootstrap stable workdir/
sudo chown -R $USER. workdir

これで /tmp/workdir にdebianがインストールされる。

chroot する

chrootするには特権が必要なので少し心が傷むが自分のマシンだからまあいいかと割り切ってsudo chrootをキメる。

sudo chroot workdir/ /bin/bash
cd /root

これで root シェルが取れる。

Debianの基本セットアップをする

最小構成のDebianでは色々とパッケージが足りなくて辛い気持ちになる。 apt update すらできないからね。

あと、 proc とか /dev/pts とかもないね。まあこのあたりはどこまでそれっぽくするかによるし、いらないセットアップな気もする。 /tmp が必要なら mkdir /tmp とでもしておけばいいと思う。 (律儀にtmpfsをmountしなくてもいいよね)

echo "deb http://ftp.jp.debian.org/debian/ jessie main contrib non-free
deb http://ftp.jp.debian.org/debian/ jessie-updates main contrib
deb-src http://ftp.jp.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.jp.debian.org/debian/ jessie-updates main contrib" > /etc/apt/sources.list
apt update

apt update したいので、sources.list を雑に用意する。(apt-getじゃなくなって久しい)。

あとは適当に必要なパッケージ、zshとかtmuxとか好きに入れる。 このあとで使うので git も入れておく。 git って以外と依存パッケージが多いねって気持ちになるがまあこんなものかもしれない。

apt install zsh tmux curl git

apt の幾つかで警告が出ることがあるが、心を痛めつつ無視して先に進める。(サンドボックスは乱暴する)

git管理を始める

ロックに $HOME で git init をキメて全ファイルをコミットする。 dotfiles用のリポジトリが用意してあればそれをcloneしておきそれもコミットする。

cd $HOME
git init
git clone https://github.com/..../dotfiles
git add .
git commit -m 'Commit all home files'

これで $HOME 以下のファイルはすべて追跡できるようになった。

dotfilesに乱暴をする

大抵の変更は git commit の時点まで戻せるので、乱暴に自分の dotfiles を書き換えてchroot環境でセットアップする。

変更が気に入らなかった場合、 git clean を使いすべての変更を捨てる。怖い場合は dry-run もある。

git clean -df
# git clean -dfn (DRY RUN)

変更がうまくいったら、適当にコミットする。このあたりはコミット粒度とかプログラミングスタイルが試される。各自いい感じにしてほしい。

コミットは chroot 環境の外からキメるのが楽。

git commit

終わりに

基本なまけものなのでこういうのは気が向いたときにしかやらない。

終わったらSandboxなので適当に捨てるといいけど、丁寧に proc とかを mount していると rm -rf したときに寒い感じがする。

技術書展2 に出ます

ところでまったく話は変わりますが、2017/4/9に行われる技術書オンリーイベント「技術書典２」に 「mochi mochi laboratory」さんと合同で参加します。 (TechBooster / 達人出版会 さん主催)

「mochi mochi laboratory」と「ゆきいろパラソル」の合同サークル 「もちもちパラソル」 です。

情報は ゆいしろさんの特設ページと、こっちでも少し情報を流していきます。

もちもちパラソル 技術書典２ 特設ページ

技術書典２

techbookfest.org

進展がありましたら更新します。

最近のこと

デレステのシンデレラキャラバンの回収は期限付き。忘れないようにしないとこうなります。つらい。

iPhoneのディスプレイ割れてる人は強制交換ペナルティ1万2000円がかかります。やったね。

冬コミ、やっぱりコミケ参加したい欲求が高いということがわかり、技術書典２に出ることにしました。夏も申し込むけど、結局同人ソフトで出ることになる…かな。漫画描けるようになりたい。

Dotenvはproductionで使わないほうがよいのではという話の続き

Rails Ruby 運用 技術系

前の話

t-cyrill.hatenablog.jp

もう二年近く前の話になりますが、昔の書いた記事のアクセスが地味に多いので、 結局自分はどうしているのかという話を少しだけ書きます。

続きを読む