2017/10/08 phpcon 2017 https://joind.in/event/japan-php-conference-2017/session05-mysql

この話はかなりコンテキスト依存なので、自分メモです。 この辺、体系的に教えてもらったこと無いので、ツッコミどころは満載です。 そのサーバの役割は何か 普通だったらサーバ管理表やサーバ管理アプリに当該サーバの役割とプロジェクトが記載されているはずです。 そもそもpingが通るか pingが通らなければ、どうしようもないです。 サーバが死んだか、gatewayが死んだか、アクセスネットワークが死んだかが考えられます。tracerouteしてみてどこが死んでいるのかしらべてみるといいでしょう。 sshで繋げるか pingが通るけど当該サーバにssh接続できない場合は、単純に重いかOOM Killerが走っている場合があります。 どうしようもなければ、IPMIもしくは管理コンソール経由でサーバを再起動する必要があるでしょう。 ロードアベレージ(LA)は高くないか 何は無くともLAの状態を見ます。
サーバ管理技術IPMI スピーカー ゆたかさん 発表資料 Googleスライド ※当初非公開としていましたが、一般公開します。(2018/3/25) 本編(16:00-17:45) 目次 IPMI の概要 BMC の呼称 OOB の機能 OOB の WEB OOB の CLI IB の機能 参考文献 IPMI とは Intelligent Platform Management Interface。読み方はアイピーエムアイ。 Intel、HP、NEC、Dell が仕様を策定。 Intel のホームページに仕様書(PDF)が無料公開されている。 ※仕様書のURLは不定期に変動するため、「Intel IPMI PDF」で検索するのがよいです。 v1.0 が 1998 年に登場。最新版は v2.0 (2015年) IPMI とは ・・・ サーバを管理するための仕組み 一部のサーバ製品(ローエンド
セキュアアクセスゲートウェイ セキュリティ専門のスタッフがいない企業さまでも安全に利用できるサービスをお求めやすい価格でご提供いたします。
VirtualboxとVagrantで作った仮想マシンを他のPCにコピーする 仮想サーバは便利だけど欠点もある。ネットワーク上に共通の環境があるわけではないので、複数人・複数環境で開発を行っているとどうしても設定などに差が出てきてしまう。例えばyumでパッケージを入れた・入れない、sshの設定をした・しない、など思い当たることは多いだろう。 …多いよね? まあ、それを解決する方法としてはchefで環境設定を行うとかいろいろあるけれど、手っ取り早いのは仮想サーバそのものをコピーして他人に渡してしまうことだろう。環境を複製しちゃうという乱暴な方法だけど、確実。 というわけで、しょっちゅう手順を忘れちゃうのでメモしておく。 仮想マシンのコピー まず、コピーしたいVagrant環境のディレクトリに移動する。いつもvagrant upしてるディレクトリだ。 cd 対象のディレクトリ vagrantの
SLA (Service-level agreement、サービス水準合意、サービス保証制度)に記載されている稼働率から保証対象外の月間ダウンタイムを計算します。 稼働割合% 少数点桁まで表示 単位 SLAの例(調査日 2014/02/13) ※最新の数字、詳しい条件、言葉の定義などは各サービスのサイトで確認してください。減額もここでは返金と記載しています。 Amazon EC2 月間使用可能時間割合 99.0% 以上 99.95% 未満 → 利用料金 10% 返金 月間使用可能時間割合 99.0% 未満 → 利用料金 30% 返金 Amazon S3 月間使用可能時間割合 99.0% 以上 99.9% 未満 → 利用料金 10% 返金 月間使用可能時間割合 99.0% 未満 → 利用料金 25% 返金 Google App Engine 月間のサーバー稼働率 99.00% 以上 99.9
皆さん今日もたくさんのサーバを相手にされていることかと思いますが、いくつかのサーバにアクセスして 1 秒間の統計情報(例えばvmstat 1 2)を集めてパッと表示したい時ってどうやってますかね?shell script を学びはじめたばっかりの僕はこんな感じで書いてました。 $ for i in host1 host2 host3; do ssh $i "vmstat 1 2 | tail -1"; done 0 0 0 329004 210836 14275360 0 0 0 2424 1410 1828 0 0 100 0 0 0 0 0 3716112 587704 25921684 0 0 0 488 1643 2026 0 0 100 0 0 1 0 0 555440 265560 14015548 0 0 0 4204 1534 2392 1 0 99 0 0 vmstatと
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 <追加したコマンド> * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
On an Amazon S3 Linux instance, I have two scripts called start_my_app and stop_my_app which start and stop forever (which in turn runs my Node.js application). I use these scripts to manually start and stop my Node.js application. So far so good. My problem: I also want to set it up such that start_my_app is run whenever the system boots up. I know that I need to add a file inside init.d and I kn
森永です。 先日セキュリティグループの各ルールにコメントを書けるようになりました。 [新機能]Security Groupのルールに説明が記載可能になりました! | Developers.IO これを機にセキュリティグループの棚卸しをしよう!という機運が高まりますよね。 ただ、セキュリティグループ一覧を見ると使っているのか、使ってないのか分からないものが多数あります。 使っていないものを管理するのも時間の無駄なので削除したいのですが、下手に消すと通信が遮断されて大変なことになる可能性もあります。 今回は使用していないセキュリティグループを洗い出す方法を検討してみます。 今回はEC2-VPCセキュリティグループのみを対象としています。 Case1: AWS Configを有効化している場合 AWS Configには紐付いているAWSリソースを洗い出せるというものです。 AWS Configを
よく訓練されたアップル信者、都元です。Amazon Linuxは初期状態でNTPによるシステムクロックの同期を行うようになっています。具体的には、ntpdがインストール済みで、自動起動もONになっています。 $ chkconfig --list ntpd ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off その設定ファイルは/etc/ntp.confにありますが、このファイルを参照した所、これら4つのNTPサーバを利用して時刻同期を行っているようです。 server 0.amazon.pool.ntp.org iburst server 1.amazon.pool.ntp.org iburst server 2.amazon.pool.ntp.org iburst server 3.amazon.pool.ntp.org iburst NTP POOL P
2014-11-11 00:00:00 -0800 Overview Redis is an excellent key/value cache that is used across many of Shokunin's customers. While redis is an great piece of software it is often difficult to obtain information about actually running it in production from an operational perspective. This article aims to discuss the necessary steps that ops teams should take before running redis in a production envir
ELBのメトリクスのステータスには、バックエンドのEC2が返したステータス(HTTPCode_Backend_XXX)と、ELB自身のステータス(HTTPCode_ELB_5XX)があります。 ELB自身のステータスコードの中には504というエラーコードがあります。この504エラーと格闘した話を書きます。 この504エラーは、CloudWatchのメトリクスで言うとHTTPCode_ELB_5XXに上がってきます。 このメトリクスは5XXという名前の通り、504以外のコードも含んでいます。 例えば、 HTTP 502: Bad Gateway (バックエンドサーバからのレスポンスがHTTPレスポンスとして解釈不能)や、 HTTP 503: Service Unavailable (突発的なアクセス増によりスケールが間に合わない時など) などがあります。 実際に504かどうかはS3に保存され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く