タグ

サーバ管理に関するitboyのブックマーク (32)

  • 自サイトの死活監視にUptime Robotが便利、iOSのプッシュ通知も設定

    うちのブログはよく落ちるので、死活監視が必要と思いつつ、別鯖が必要になるためそのままにしていたのですが、Uptime Robotという死活監視サービスを見知ったので一応書いておきます。 登録したサイト等を5分ごとに死活監視。異常があれば通知してくれるというものです。 設定は非常に簡単 このブログの死活監視を設定します。 Monitor Type* 「HTTP(s)」を指定 Friendly Name* このブログなので「ひとりぶろぐ」を指定 URL* 「http://hitoriblog.com/」を指定 Aert contacts to notify 登録に使った自分のメールアドレスのチェックボックスをオン 一番下の「Add Monitor」を押して完了。 これで、もしブログが落ちたらメールが飛んでくるはずです。(続きは[Read More]から) メール以外の通知方法を設定 「My S

    自サイトの死活監視にUptime Robotが便利、iOSのプッシュ通知も設定
  • 大容量ファイルのSCP転送を高速にする方法 - 元RX-7乗りの適当な日々

    比較的大きいサイズのファイルをSCPで転送することがあって、できるだけ高速化してみたかったので、色々試してみたメモ。 scpというかsshには、暗号化方式と圧縮有無の指定があるので、それらのベンチマークを。 尚、以下は、SSH v2が対象です。v1はかなり遅かったのと、そもそも使っていないので試していません。 (追記: 2019/11) エントリの情報は既に古いため、以下のエントリにて再検証しています。あわせてご覧くださいませ。 ベンチマークで利用した環境 [Server1] <=> [Gigabit Switching Hub] <=> [Server2] Server1 (HP ML115 G5) AMD Phenom 9950, 8GB, RAMディスク使用, Gigabit Ethernet Server2 (HP ML115 G1) AMD Opteron 1210, 4GB,

    大容量ファイルのSCP転送を高速にする方法 - 元RX-7乗りの適当な日々
  • IO Accounting 機能で I/O 負荷の高いプロセスを特定

    随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を

  • これぐらいやっとけ 〜Linuxサーバのセキュリティ設定〜 - nabeの雑記帳

    管理中のサーバで行っているセキュリティ設定を公開します。当はこういうことを公開するのはよろしくないのですが、脆弱サーバが氾濫している現状そこが踏み台となってsshアタックされるのも迷惑極まりないので、最低限やっとけという内容でまとめました。*1 起動サービスと概要 iptables/Firewallの設定 iptablesの中身 limit-burstについて hashlimitについて hosts.allow/hosts.deny(TCP Wrapper)の設定 sshdの設定 その他の設定 Apacheの設定 Postfixの設定 Dovecotの設定 まとめ はてブさんは #の切り分けやめてくれないかな……。 起動サービスと概要 Apache (www) sshd smtp/pop bind (DNS) ntpd いくつかの注意点。 sftpで十分なのでftpdは使わない。WinS

    これぐらいやっとけ 〜Linuxサーバのセキュリティ設定〜 - nabeの雑記帳
  • Linuxのサーバをリモートから強制的にOSリブートする - 元RX-7乗りの適当な日々

    先日、諸々の都合で遠隔にあるテスト環境のサーバ(Linux)のカーネルパラメータを弄っていたのですが、ちょっと設定(メモリまわり)がイキすぎてしまいw、コマンド実行というかforkできなくなってしまった(Cannot allocate memory...)。 んで、shutdownコマンドも実行できなくなったので、直そうと思ったのですが、色々弄った&時間がなかったこともあり、一旦OSを再起動しちゃいたいな、と(汗 が、遠隔にあるサーバなので、物理的な電源スイッチON/OFFができない(厳密には出来る環境ではあったのですが、このサーバはそこに入ってなかったw)。ので、SysRqキーを送ることにした。 やり方 少し無理矢理感はありますが、 # echo b > /proc/sysrq-triggerを実行すると、強制的にリブートがかかります。 ただし、ファイルシステムのsyncとかumount

    Linuxのサーバをリモートから強制的にOSリブートする - 元RX-7乗りの適当な日々
  • TwitterがBitTorrentで高速にデプロイしている仕組みについて

    Twitterは、同社の何千台ものサーバに対してバイナリをデプロイする場合に、ピア・ツー・ピアシステムのBitTorrentを利用したツール「Murder」を用いていると、7月1日の記事「Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」」で紹介しました。 FacebookでもBitTorrentによる大規模なデプロイが高速に行われていることは、7月16日の記事「Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側」で紹介しました。 どうやら大規模システムにおけるデプロイではBitTorrentの利用が進んでいるようです。 7月15日付けのTwitter Engineering Blogに、Twitterエンジニア、Larry Gadea氏による「

    TwitterがBitTorrentで高速にデプロイしている仕組みについて
  • 『アメーバを支える自作サーバのいままでとこれから』

    初めましての方は初めまして。知ってらっしゃる方はありがとうございます(※)。 アメーバでインフラエンジニアをしている桑野章弘と申します。id:akuwanoと言ったり、@kuwa_twでtwitterもやっています。 ※M.S.注...「桑野トラップ」でご存知の方、その節はどうも申し訳ありませんでした。 twitterではどうでもいいことかカレーの事をメインにつぶやいております。(って言ったら誰もフォローしませんよね、、、参加した勉強会の実況等もしています) 色々話したいことはあったりするのですが、今回は私の最初のエントリということもありまして「アメーバの自作サーバのこれまでとこれから」についてお話しさせていただければと思います。 え?キャッチーだからとかじゃ、、、ないですよ? ■ミルフィーユサーバの紹介 、、、それでは、気を取り直して。 まず、現在アメーバで主に使われている自作サーバと言

    『アメーバを支える自作サーバのいままでとこれから』
  • 『アメーバサーチにApache Solr 1.4をつかってみた』

    皆様、こんにちわ 新規開発局コアテクGで、現在はサービスの管理ツールなどの開発を担当しているGakuです。 現在は担当していないのですが、以前に担当しており、全面的に作り直したアメーバサーチについて書かせていただこうかと思います(一番大変だったんですが、一番楽しい開発でした)。 ■以前のアメーバサーチ Lucene使用(RMI機能を使ってました) 検索対象:6000万件ほど(直近3ヶ月~6ヶ月) スケールアップがしにくいつくり Luceneのバージョンアップもむずかしい(バージョンアップ後はRMIは非推奨化予定でした。使えないなと) 「アクセス過多のため・・・・・」と検索できない事が頻発 QPS(一秒辺りの検索数) 50ぐらい(4セット合計で) 急激にアメブロの記事数が増えていた為、明らかにキャパオーバに陥ってしまっていました。 それで・・・・・・・・・ ユーザの方々からおおいにお怒りの声

    『アメーバサーチにApache Solr 1.4をつかってみた』
  • http://japan.internet.com/webtech/20101109/5.html?rss

  • 顧客のサーバにパッチを適用する際のベストプラクティス

    文:Erik Eckel(Special to TechRepublic) 翻訳校正:村上雅章・野崎裕子 2010-10-19 08:00 数多くのITコンサルタントが、月々の保守契約の一環として、顧客の所有しているサーバに対する適切なパッチの適用を保証するというサービスパッケージを提供している。またITコンサルタントによっては、パッチやアップデートの適用を通じてOSを最新の状態に保ち続けるという責任を負っている場合もある。いずれの場合でも、AppleLinuxMicrosoftから提供されるセキュリティパッチやパフォーマンスアップデート、その他の修正モジュールのダウンロードやインストールを定期的に行うことは、大した作業ではないと考えてしまいがちである。しかし、OSに対する誤ったアップデートをまずいタイミングで適用してしまうと、顧客の業務に大きな影響が及ぼされるというのは、経験豊富な技

    顧客のサーバにパッチを適用する際のベストプラクティス
  • Linux等でのログのモニタリングで簡単にアラートをキャッチするワンライナー - 元RX-7乗りの適当な日々

    昔、『「ping -a」で音が鳴る!』なエントリでも書いたのですが、何らかをリアルタイムにチェック/監視したい時に、視覚だけではなくアラート音が一緒に出ると、モニタリングしやすいものです。 というわけで、Linuxなんかで、とあるログファイルの出力から、ある文字列が検出された際に、ビープ音を鳴らすワンライナーは以下。 $ tail -f ログファイル | sed -e 's/\(対象文字列\)/\1^G/'上記を実行中に、指定ログファイルに対象文字列が出力されるとビープ(Beep)音が鳴るはず。 「^G」(0x07)の部分が、ASCIIのBELキャラクタのリテラルです。 $ echo -n "^G"などとしてやれば、ベル(ビープ音)が鳴りますよね。 ちなみに、「^G」は、[Ctrl-V] ⇒ [Ctrl-G] の順に入力してやればOK。emacsだと[Ctrl-Q] ⇒ [Ctrl-G]か

    Linux等でのログのモニタリングで簡単にアラートをキャッチするワンライナー - 元RX-7乗りの適当な日々
  • グリーの開発環境(歴史と概要) | GREE Engineering

    こんにちは。グリーでインフラ的なお仕事をしているsotarokです。今回は、グリーの開発環境についてお話します。 グリーの開発環境 開発環境どうするか、という問題はエンジニアリングをしている会社であれば誰しも一度は悩んだことのある問題だと思います。開発環境の作り方は、会社やサービスの規模、事業の形態などによって様々ですし、割と小さな規模から「歴史的な経緯」を経て成長してくることが多く、これといったスタンダードがあるわけでもありません。 グリーでも初期の頃から、いくつかの経緯を経て現在の開発環境があります。これは、特に画期的な開発環境やスタンダードに合わせてつくったわけではなく、日々の業務のなかで、あれこれ困ったことやより便利にしたいことなどを解決していくうちに作り上げられたものです。 今回は、グリーの開発環境の移り変わりと、今後の開発環境づくりについてお話させていただきます。 初期の頃の開

    グリーの開発環境(歴史と概要) | GREE Engineering
  • 米Red Hat、REHLのサポートを3年延長する新サービス「Extended Life Cycle Support」を発表 | OSDN Magazine

    米Red Hatは8月19日、Linuxディストリビューション「Red Hat Enterprise Linux(RHEL)」のサポートを3年追加する有料サービス「Extended Life Cycle Support(ELS)」を発表した。RHELのサポートは通常7年だが、ELS追加購入により、10年まで延長できる。 ELSはRHELの有料サポートサービス。Red Hatは通常、メジャーリリースのサポートを初期出荷から7年としているが、ELSを購入することで最大10年までサポートを受けられる。たとえば、2003年に初期出荷した「Red Hat Enterprise Linux 3」の場合、2010年10月にサポートが終了するが、ELS購入により2013年10月まで延長できる。 ただしELSが対象とするサービスは限定的で、サポート対象外のものもあるようだ。Red Hatでは、重要なバグや影

    米Red Hat、REHLのサポートを3年延長する新サービス「Extended Life Cycle Support」を発表 | OSDN Magazine
  • グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering

    はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる

    グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
  • 最近知ったLinux/UNIXの小技 - harry’s memorandum

    最近知って結構ショックを受けた。 touch hoge.txt と似たような機能。*1 $ > hoge.txt $ ls -l hoge.txt -rw-r--r-- 1 root root 0 Jul 10 03:15 hoge.txt lessでtail -f ができる。 $ sudo less +F /var/log/messages SSHでリモートサーバに対して色々 リモート先のファイルをsortして比較。パスフレーズなしにするか、ssh-agentを使用するかしてください。 $ diff <(sort /home/user/.bashrc) <(ssh user@hostname "sort /home/user/.bashrc") リモートサーバのファイルを編集 $ vim scp://user@hostname//home/user/.bashrc sambaのコマンドで

    最近知ったLinux/UNIXの小技 - harry’s memorandum
    itboy
    itboy 2010/07/12
    え?そんなんできるんですか?
  • Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」

    Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」 米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」の、Twitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」(クジラの腹の中:Twitterでの運用)を紹介をしています。 この記事は「「Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」」の続きです。 Twitterのサブシステム「loony」「Murder」「memcached」 ここからはTwitterのサブシステムについて紹介しよう。 T

    Twitterの大規模システム運用技術、あるいはクジラの腹の中(後編)~Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」
  • ヤフーにおけるパッケージ管理 - Yahoo! JAPAN Tech Blog

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R&D統括部 開発推進室 セキュリティプラットフォーム技術の戸田 薫です。 個人的に自宅では、 FreeBSD でよく遊んでいて、FreeBSDのパッケージ管理には、portsnap、portupgrade を利用していますが、ヤフーでは独自の方法で行われます。 その背景としてヤフーには、平均15億以上のPVを支えるためやサービスの付加価値のために何万台ものサーバがあり、サービスやシステムごとに大規模なシステムを構成する必要があるため、一般的なパッケージ管理システムよりもより柔軟で効率的なパッケージ管理が必要となっています。 今回は、ヤフーにおけるパッケージの管理についてご紹介します。 ヤフーインストーラ ヤフーでは

    ヤフーにおけるパッケージ管理 - Yahoo! JAPAN Tech Blog
  • ウノウラボ Unoh Labs: 快適なsshクライアント生活

    はじめまして、HIROKIです。 大規模コンテンツの開発に携わっていると数多くのサーバにsshでログインすることになります。その手間を軽減するために $HOME/.ssh/config を設定してみます。 sshコマンドを簡略化 例えば dev01.labs.unoh.netというサーバにsshでログインするのであれば、 $ ssh -i ~/.ssh/id_rsa.unoh hiroki@dev01.labs.unoh.net という感じのコマンドでログインしているかと思います。 これを $ ssh dev01 でログインできるように設定してみましょう。 Host dev01 User hiroki HostName dev01.labs.unoh.net IdentityFile ~/.ssh/id_rsa.unoh 秘密鍵を複数使いわけている人はIdentityFileを指定すると便

  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • Kazuho@Cybozu Labs: 既製品の管理ツールを使わないことでウェブサービスの TCO を下げる話について hbstudy#8 で話してきた件

    昨日、hbstudy#8 で話をする機会をいただくことができたので、Nagios や Amanda といった既製品の管理ツールやバックアップツールを使わずに内製したことで「パストラック」の運用コストを下げた、という話をしてきました。 もちろん、「既製品を使わない」というのもひとつの手段にすぎませんから、それを無闇にお勧めするつもりはありません。ただ、小回りの効くツールを組み合わせる手法にも十分な競争力があるという点、あるいはその事例として参考になれば幸いです。 スライドはこちら。hbstudy 運営の皆様、話を聞いてくださった皆様、ありがとうございました。