AWSにおけるSSL証明書の基本的な取扱い | 外道父の匠
多くの企業が、今年中にWebサービスの暗号化を進めなくてはいけなくなったかと思います。 Webに接続するiOSアプリは2017年1月からHTTPSの使用が絶対条件になる、デベロッパーはご注意を | TechCrunch Japan ということで、基本的な内容ではありますが、AWSにおけるSSL証明書の扱いについて復習してみます。 AWSで扱う証明書の種類 ここでいう種類とは、EV SSL だの ワイルドカードだの、証明書の製品としての種類ではありません。 １つは AWS Certificate Manager（以下、ACM）の無償証明書、もう１つは従来のSSLサーバ証明書販売サイトで購入する有償証明書、の２種類となります。 それぞれの証明書を、AWSのリソースにどのように登録し、運用していくかについてまとめていきます。 ACMの証明書を利用する 2016年1月にリリースされ、5月にはTok
Amazon Auroraを始めるためのパラメータ資料 | 外道父の匠
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の２つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
Percona XtraBackupの抽出と圧縮の並列処理 | 外道父の匠
久々にXtraBackupの話題です。 以前に紹介した基本手順では、tarアーカイブをgzip圧縮していました。 実はこれよりもっと速い方法がありまして、データサイズが大きくなると必須になってくるのではないかと思います。その、計測内容と結果について紹介していきたいと思います。 リンク 本件に関係ありそうなドキュメントのリンクになります。 The xtrabackup Option Reference Streaming and Compressing Backups The xbstream Binary Accelerating with –parallel copy and –compress-threads Making a Compressed Backup (qpress) 本家ブログのベンチマークもあります。 Compression for InnoDB backup – My
Fusion-io ioDriveの検討資料～運用設定編～ | 外道父の匠
サーバ筐体 コネクタは PCI Express x16 ですが、必ずサーバベンダー経由の購入のため、どの筐体で利用するかはベンダーと相談することになります。 寿命検知 SNMP SNMP/SMI-S を利用して、予備領域の残量やこれまでの読み書き量の監視ができます。 ioManager GUIツールでの状態確認もできます。 デバイス・ファイルフォーマットの流れ デバイスの認識 iomemory-vsl パッケージを入れるとDuoなら /dev/fct0, /dev/fct1 として認識されます ioDriveの論理フォーマット ブロックサイズ4Kbyteとしています。-s オプションで実効容量をいじれますが、普通は不要です。
Percona Server 機能紹介 (1) InnoDB I/O Scalability | 外道父の匠
Percona Serverの追加機能はたくさんありますが、とても便利なものから実験的なものまで様々です。ドキュメントに設定やStatusは存在するけど説明が全くないものも多く、そういった機能は”提供するけど自由に解釈して使ってね”という程度にとらえて挑戦するとよいです。 そんな多くの機能を少しずつ紹介できればと思います。 ドキュメント このページにキッチリまとまっています。とても面白いのでちょこちょこ読むのをオススメします。 Percona Server – Documentation DeviceI/O対策 こちらからの紹介です。 Improved InnoDB I/O Scalability checkpoint I/O 平均化 データ更新量が大きくなると、WALからテーブルスペースへの反映のために 瞬間的にDiskI/Oを食うようになりますが、この負荷を均してくれる機能です。 古い
MySQL + ioDrive + XFSにおけるbinlogローテート問題 | 外道父の匠
前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi
Percona Server 5.5にて10秒間隔でDisk I/Oが重くなる問題 | 外道父の匠
久しぶりにDBAとしてお手伝いした時の汚いメモになります。 Percona Server5.5＋ioDriveのMySQLで、イベント時やピークタイムにアプリケーションからのDB利用が重くなる、ということで調査から対応方法まで考えてみました。 問題点の大雑把な特定 高トラフィック時に、RubyからMySQLの接続やクエリがちょこちょこ重くなり、レスポンス速度に影響が出る、とのこと。で調査開始。今回のPercona Serverのバージョンは 5.5.34 でした。 top -d1 で触診してみると、謎の10秒間隔でiowaitが5～10％に上がることを確認 5分平均のiowaitグラフを見ても、ピーク時は50～60％であることを確認。ioDriveでこれはイカン dstat で見ると、平時はwrite数MB/s～十数MB/sのところが、やはり10秒間隔でwrite 数百MBを確認。ピーク時
OpenStackのpolicy.jsonを個別ユーザ仕様にする | 外道父の匠
コンポーネント毎に設置されている policy.json ですが、デフォルト設定だけでも多いのに、隠れ設定もいっぱいあるため把握するのが非常に面倒くさいです。 が、デフォだと他人が作成したVMを勝手に削除したり色々できてしまうので、 グッと我慢して、隠れ設定のページを見つけたり、他人のVMをイジれないようにしました。 Nova 目的は、別ユーザが作成したVMを削除したり、コンソール覗いたり、Volumeを弄ったり、スナップショット取ったりできないようにすることです。参考にしたページはこちら Re: [rhos-list] Control Access to instance termination /etc/nova/policy.json "admin_or_user": "is_admin:True or user_id:%(user_id)s", "compute:attach_vo
OpenStack Grizzly構築 on Wheezy (9) ネットワーク作成 | 外道父の匠
ひととおりコンポーネントの設定が終わったところで、ネットワークの作成を行います。 ここは組みたい構成によってちょこちょこ内容が変わるので、１つの参考にしていただけると。 構成について 絵は面倒くさいので箇条書きで説明します。 adminプロジェクトが全体で１つのルータを持ちます adminプロジェクトは外部ネットワークを持ち、ルータのExternalG/Wとします adminプロジェクトは内部ネットワークを持ち、ルータに紐付けます 一般プロジェクトは内部ネットワークを持ち、同じルータに紐付けます 外部ネットワークのG/WアドレスをControllerNodeに割り当て、内部ネットワークへのルーティングをルータのG/Wに送ることで、Linux Network Namespaceを介さず内外を疎通します 今回の構成・運用で重要なポイントは、いわゆるFloatingIPはVMに割り当てないという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
