読者です 読者をやめる 読者になる 読者になる

smallpalace's blog

鯖缶主婦の日々の記録です

OSSカンファレンス20140228のメモ

Chef 勉強会・セミナー

こんにちわ。smallpalaceです。

このまえ行ったセミナーのメモをすっかり公開しわすれてまして今更ですが公開します。

 

zabbix2.0をつかってみよう

途中参加だったのもあり以下が気になったということだけメモっておきます。

perconaモニタリングプラグインforZabbix(mysqlのやつ)
http://www.percona.com/downloads/percona-monitoring-plugins/LATEST/

--------------------------------

エンジンヤードの安藤さんのchefのお話
http://www.engineyard.co.jp/blog/2014/chef-at-osc-tokyo/


chefが公開されたのは2008年だけどエンジンヤードはその前からchefを使っていた
開発者のアダムさんが演じニャー度ではたらいてた
フリッカーの発表で初めてDevOpsという言葉が出てきた

組織の文化とツールとで変化の速度が速くなったのに対応

Infrastructure as Code
台数で精度が変わらない、正確・高速
Chefは実現する手段の一つ

完璧にこなすのが難しい手順書にくらべて一度書いたらそのとおりに動くコード。
ツールで人を減らすと。

Chef等をつかってビジネスの速度の変化に対応していきたいという機運
AnsibleとかPuppetでもいい

Chef
・構成管理ツール
・v11.10が最新
Ruby
・冪等性が特徴
・高い人気

Squid Chef Recipeで検索してみるとイカ料理がでてくるw

採用事例
・EnginYard、2万のお客様すべてにchefつかってる
Facebook、1万台以上のサーバ
・Prezi(プレッツィ)
サイバーエージェント(pig)
・グリー

けっこうつかわれている

構成の話
自分のPCでクックブックを書く(ワークステーション
chefサーバにアップロード(ホステドとか色々)、knifeをつかう
Chefクライアントがクックブックをとってきて設定される
拡張性があり、FBはこの仕組みで数万台規模を運用してる
ケーブルつないで電源あげたらkickスタートとかでchefサーバにつないでセットアップとかできる
小規模の開発環境、chef-soloがつかえる(自動インストーラ
大規模になったらchefサーバに行くのが基本
gem install chefはふるい手法
現在のChefは必要なRubyなどを同梱している
/opt/chefはイカにインストールされる
chefにさらにGemを追加する際は注意

クックブック
rubyでかかれた小さなプログラム

Ohaiをつかったノード情報の取得
設定ファイルの動的な生成

Chef/Chef-soloの実行
・chefClientのcronからの実行
・デーモン化も一応可能(メモリリークしやすい)
・why run(dry run)も可能
・knife-solo
・なるべく頻繁に実行するのが望ましい

勉強会動画とかあるらしい

Chefをさらに活用するポイント
Chefつかってる人の悩み
バージョンの違い
 ビックバージョンというバージョンの振り方を採用している
 Chef0.8、10、11
 非互換のクックブックの書式がちがうとかある
  安藤さんがブログに書いてるchef11最新情報
  すでにchefがある環境をつかうとかの場合注意する必要がある
chefの内部動作
 クックブックは上から下に書いたとおりに実行されるわけではない
 リソースコレクションと収束
 塊をブロックオブジェクトというリストを作り、リソースコレクションにしてメモリに展開し収束する

 コンパイル⇒収束(Converge)⇒通知(Notification)

 Notificationはリスタートかけてまわる(詳しくはブログ参照)

クックブックの書き方にはみんな困る
 みんなけっこう書き直してる
 新規開発したソフトのコードを10年なおしてないとかじゃなくて継続的にメンテして実行する

クックブックのCIは欠かせない
・Infrastructure as Code
・テストのないコードはレガシーコード
・クックブックが常に健全であることを担保
単体テストを行う
単体テストを継続的に実行する(CI)

クックブックのテストに使うツール
・Berkshelf/Librarian-chef
 クックブックの収集
・foodcritic
 クックブックの規約チェック
・Test-kitchen
 クックブックの単体テスト
・Serverspec
 サーバの状態の単体テスト

テストスイートの構成
Jenkins・Berkchelf・クックブック・foodcritic・仮想マシンVagrantとか実環境・Chef solo・Serverspec
Chef ZeroというのはChefサーバのような動きをするもの

巨大なテストスイートだけどそれぞれ担当してるテストが異なる

test-kitchenのつかいかた
最近は結構キータに載ってる

コミュニティクックブック
・人類の叡智を結集
・多様なプラットフォームに対応
・わかれば便利なものかゴミか
ちょっとうまくまわってない
皆様に提案
・クックブックを書こう
・クックブックをテストしよう
・コミュニティに登録しよう
オープンソースのフローでコード改善

fbでchefの日本語コミュニティがある

苦労したくない場合はエンジンヤードつかってみてね。
監視してるし運用提供してる

おまけ
「Chef実践入門」
が春の連休前くらいに出ます。

個人的に予約注文したいです。

-----------------------------------

drbd8.3の開発終了に伴う情報

drbd8.3.16までで終了
よっぽどスゴイバグが出ない限りここまで。
サポートはMLベースで継続
機能強化とバグ修正は終了
商用サポートユーザは最長2022年までサポート
RHEL5の終了まで
8.4
今後のメイン

8.3vs8.4
いぶし銀てきな改良が。
ボリュームの導入
多段スタック(8.4.2〜
アクティビティログの改良(8.4.3〜、パフォーマンス改善
構文の変更
 8.3構文も引き続きサポート
リソースおよびボリューム
 リソースを2つかいてたところを
 ひとつのリソース内に2つのボリュームをパックするみたいなことができる
 設定ファイルの書き方も異なりリソース内にボリュームを書く

・リソースおよびボリューム
ディスクI/Oの書き込み順序
複数コネクション(8.3)
デバイスごとの書き込み順序は維持される
 デバイスをまたぐ書き込み順序は保障されない
単一コネクション(8.4)
 デバイスをまたぐ書き込み順序も保障される

8.3までは、クラッシュ時にデータ整合性は保障されない
8.4はクラッシュ時もデータ整合性が保障される

物理ボリューム・ボリュームグループ・論理ボリューム
論理ボリュームのまたがり具合によっては8.4でないと整合性がたもてない場合がある

多段スタック
従来は2段スタックをサポート
 最大4ノードのレプリケーションがサポートされていた
8.4からは段数制限を解除

そんなことできたのを知りませんでした。
同じデバイスに複数のDRBDリソースを設定してそれぞれ別のところに同期取るみたいな。
ただし8だと1:1フルメッシュで設定する必要があり9から1:nの設定が可能になるらしい。

昼間とめといてピーク時以外夜などに同期とる的な運用もできるらしい。
多段にしててもそういう運用ならパフォーマンス大丈夫。wanの同期とる場合は夜間のみとかよくあるそう。

・アクティビティログの改良(8.4.3〜
 アクティビティログはdrbdの一定のブロックを区切っていて
 ホットなエリアとコールドエリアと識別してる
 ホットは書き込みが行われてるところ
 ホットは同期がとれてる保障がないエリア。
 完全に同期とれたことを確認できるとコールドに戻る(コールドは同期がとれてるところ)
 ひとつのブロックはたしか4MB
 これがアクティビティログ。
 ホットエリアはディスクのメタデータに書き込んでる
 引き継いだときはそれをつかってもどすなど。
 内部ロジックの変更点
 ・オーバヘッドを最大64倍改善
  ・多数のコネクションをもつDB処理などに顕著な効果がみられた
 ・アクティブエクステント最大数を65534に拡大
(たくさんのエリアがほっとになれるので、ランダムアクセスが多いDBとかに有利
 スタートは全部読み込むのに時間がかかる)
 最近の高速ストレージに対応するための改良
 高速ドライブをつかってDRBD構築するなら8.4.3以降がいい

・設定ファイルの構文が変更された
 ・booleanタイプのパラメータにはyes/noを指定
 ・syncerセクションが解体されてnetにはいることに
 ・protocolはnetセクションのパラメータになった
 ・optionsセクションが新設された
 8.4は8.3の構文を解釈がかのう

・オンラインのまま
  ・プロとこるを変更できる
  ・シングル⇔デュアルプライマリを切り替えられる
・drbdadmの構文がかかわった
 8.3
 drbdadm [option] comand resouce
 8.4
  drbdadm command [option] resouce
・同期のデフォルトが固定速度から可変速度に変更
・いくつかのデフォルト値の変更

DRBD9
・drbd-9.0.0pre8.tar.gz
・正式リリースは本年後半の見込み
・関連プロジェクトDRBDmanager
1:nレプリケーション
n:xxかききれず
・スタッキングvs多ノード
 スタックしなくても1:nで動くようになる
 あらかじめ最大ノード数を想定したメタデータを作成しておけば複数同期とれるようになる
 アクティビティログのオーバヘッドが軽減される
 ノードの動的追加削除が可能になる
 フルメッシュじゃなくてツリー構造にできるかも
自動プロモート
 ・drbd領域にアクセスすれば自動的にプライマリに昇格する
 クラスタマネージャとの組み合わせが容易になる
DRBDマネージャ
 drbdのデバイス追加・削除の儀式を肩代わりする
 LVをつくる(lvcreate)、設定ファイルを書く、
 メタデータを作る(drbdadm create-md)、初期同期する(drbdadm -overwrite-data-of-peer)
 ⇒drbdmanage new-volume r0 50 deploy 4

OSSバイナリと認定バイナリ
http://oss.linbit.com/drbd/
コミュニティバイナリ
RHEL,CENTOS6ならATrpms,ELRepo
GPLベースなので同じ
ソースコードに違いはありません
認定バイナリの付加価値は
 ・開発ベンダによるサポートが受けられる
 ・最長2022年までの長期サポート
 ・ホットフィックスによる修正版提供(ゴールド以上)
 ・ただしサポート費用が必要

-----------------------------------------

Apacheコミッターが見たApache Vs Nginx

アーキテクチャとコミュニティ、機能その他の違いと感想を軽く。

さとうさん @tksst1024
野村総研OSSソリューション推進室でApacheのサポート他やってる

コミッターとは
オープンソース開発コミュニティにおいては通常バージョン管理システムリポジトリ
インターネットで読み取りが公開されてる
書き込みアクセスはコミッターに制限されている
コミッター以外はソースコードの貢献にはコミッターを通す必要がある
ApacheSoftwareFoundationにおいては、各プロジェクトの運営委員会(PMC)が、
よくプロジェクトに貢献している人について、「コミッターになってもらったほうがいい」
と判断されたら勧誘される

さとうさんは、コミッターだけど大規模なことはしたことがないバグ修正とか数行の修正ですむような。
報告されたバグについてコメントしたり。地味な活動でも貢献が認められてコミッターになれたりするそうです。

Apacheのnginxの違いをアーキテクチャの観点で話ます

対象:
 HTTPの仕組みざっくりイメージできる人(テキストベースとか、リクエストしてレスポンスが返ってきてるとか
 webブラウザでURLにアクセスすると何か表示されるという理解だけだと厳しいかも
 非同期i?O、ノンブロッキングi/o、多重化とかわかるひとは眠いかも

apacheマルチプロセス・マルチスレッド

超ざっくりなHTTPサーバ実装:
accept()TCP接続をOSから受け取る
read()クライアントからのリクエストを読む
 コンテンツ生成
write()クライアントにレスポンスを送信する
さまざまな処理、ログなど

複数接続を同時に扱えないと待たされると言う話し
それを解決するのがマルチプロセス・マルチスレッド

プロセスやスレッドをつかって複数の処理者を作り出すことで、同時アクセスに対応
 処理者の数=同時アクセス可能数

apacheのpreforkMPM、workerMPMはブロックを複数個(MaxClients)もつ
シンプルでわかりやすいアーキテクチャ
プロセスもスレッドも、それ自体のオーバーヘッドが大きい
 メモリ、CPUのコンテキストスイッチ
⇒大きな同時接続数に対応しようとすれば、それだけ上記負荷が増える

nginxはイベント駆動のアーキテクチャです
 処理者が一人で複数の接続を扱います
 どういうことかというと。。
なお、apacheのEVENTMPMもイベント駆動

write、reaed、Acceptを処理をわけ、上にイベント駆動マシンで可能になった処理に振り分ける
各処理のあとにイベント駆動マシンに戻る
事前に調べるので各ブロックの処理はとまらない
イベント駆動マシンは同時に複数個のTCP接続をさばく
可能になってから処理が行われるのでとまらない。

同時接続数が増えてもプロセスやスレッドは増えないため性能が高い
処理の流れを淡々と並べるマルチプロセスマルチスレッドに比べて
イベントをバラバラと書くためソースコードが複雑で分かりにくいという意見がある

説明不十分なところ
readがすぐおわるのは本当か?
静的ファイルで大きいならディスクから読まなきゃ、プロキシの場合はバックエンドと通信しなきゃ
CGIとかPHPとかJavaのアプリの場合DBやファイルアクセスがあるかもしれない

「すぐ終わるが崩れる」と、それだけ同時アクセスを阻害します。

イベント駆動なのでもう少し細かくイベントが分かれている
ファイルの読み込み、CGIとの通信、ログ書き込みとかも。

ApcheのEventMPMはイベントになってる処理は一部。ngixは多数イベントとして扱うので、
アーキテクチャはnginxのほうが優れている

処理者は1つのCPUしか使用できないので実際はCPU数にあわせてイベント駆動のスレッドを増やすことが多い

QA:
Qセキュリティに対する安定度
なおしてもどしてが多いapache
Aセキュリティは明確にこたえられない、apacheはそんなに重大なのは今はでてない
 なおしてもどしてはトランクは気にしないでいいとおもう
Apache3.0は正式ではない
開発コミュニティでは話はあるけどまだ公式ではない

-------------------------------

2日目は娘の咳のテープをもらいに小児科に行ったので無理でした。無念。yokuさんのmysqlのチューニングのスライドを後でみて満足した感じでした。

http://www.slideshare.net/yoku0825/mysql-31789267 

以上みていただいてありがとうございました。