Home 旅レポ一覧 MyPhoto 売れ筋インフォ  TechBlog  LinkBox  RSSr(New!)  SiteMap  Album  日記  blog  MyPage  About
 
icon icon
 



  • oss

  • オープンソース活用 Emacs編に戻る



  • atコマンドでteatimeに優先度を下げてバックアップを実行

  • at teatime[RET]
    nice tar czf backup.tar.gz /target_dir/* [RET]
    [Ctrl+D]で登録完了

    atq [RET] //キューを表示する

    値は-20から19
    nice -n 5 コマンド のように指定する
    省略すると10で -20が最も優先

    ※注:大丈夫だと思いますが、いきなり本番環境で試すのではなく、念のため
    試験環境で試してから使用してください。コマンドが環境に入っていない
    ことも多々あります。



  • tarコマンドオプション

  • c:書庫を新規作成(create)
    z:gzip圧縮
    f:ファイル名を指定

    x:ファイルを取り出す
    v:一覧表示
    f:ファイル名を指定




  • rsyncでネットワークバックアップ

  • a:アーカイブモード
    v:転送情報を表示
    z:圧縮



  • Ubuntu12.10-desktopを試験導入

  • 多少要求スペックが高いもののなかなかの仕上がり。
    sudo apt-get install emacs24
    man-dbエラーが出た場合はいったん削除してから再インストールする。
    グラフィックチップがRadeonだったのでこちらも試してみました。



  • Ubuntu12.04-LTSを試験導入

  • なかなかの仕上がり。LAMP環境の話も多いしそれを前提として組まれている
    このバージョンも良いかも。http://jp.releases.ubuntu.com/12.04.2/



  • Vine6.1を試験導入

  • デバイスの認識も特に問題なく導入完了。安定しているけれど
    Emacsの入力部分で少し難があり anthyに切り替え SCIM(Ctrl-¥)
    sudo apt-get install emacs24
    PHPも5.3系で設定ファイルも随所で日本語化されており、サーバ兼用にする場合は
    かなり良い。



  • Ubuntu-server-12.04を試験導入

  • LAMP環境を整えたければかなり有効。安定している。要求スペックもそれほど高くない。



  • CentOS6.X系を試験導入

  • ずいぶん前に構築したCentOS5.X系が多少古くなって来たため、移行を検討中。
    apache mysql php samba ftp cvs svn



  • メモ専用機を準備中

  • 2013/04/24 19:43:09

    サブ機としてEmacs専用機を準備中。
    何かのたびにウインドウ切り替えをしなくて済めば
    かなり効率化が期待出来る。

    作文用のEmacs専用機を調整中
    ちょうどいい具合にチューニング
    ・このマシンは熱暴走するのでセーブぎみ(cpufrequtils)
    ・非常に快適に日本語入力できる
    ・レスポンスもきびきびしていてちょうどいい
    ・emacs日本語環境が整っている

    Ubuntu12.04 desktopをベースに再構築することになりました。
    メモをとるには十分な環境になった
    長文作成にちょうどいい

    Ubuntuの場合12の部分は年度を示し04は期(月)を示します。
    12.04ならば2012年の4月ということです。多少古いものを
    使用しているのはちょっと古いパソコンをEmacs専用機として
    仕上げようというこころみの為です。夏場は熱暴走してよく落ちる
    為多少動作周波数を下げて動かすようにしてあります。

    Emacs導入
    sudo apt-get install emacs23

    samba導入
    sudo apt-get install samba
    ファイル共有 Ubuntu12.04の場合GUIから操作する
     共有したいディレクトリを右クリック>共有のオプション

    MacOSXからUbuntu-sambaに接続
     オリジナルの項目が見つからないため・・・ というエラーがでて接続出来ない
    avahi-daemon と netatalkを入れると良いようだ
     sudo apt-get install avahi-daemon netatalk -y
    無事接続出来ました。ログインに失敗した場合も発生する。

    sudo tasksel install lamp-server
    sudo apt-get install php5 phpmyadmin

    UbuntuでUserdirを有効にする
    #sudo apt-get install apache2
    #a2enmod userdir

    標準の状態だとユーザディレクトリでPHPが実行出来ない
    設定になっている。
    #php_admin_value engine Off
    #コメントアウトする。

    CPUの周波数を変更
    sudo apt-get install cpufrequtils

    sudo cp /usr/share/doc/cpufrequtils/examples/cpufrequtils.sample /etc/default/cpufrequtils
    sudo vi /etc/default/cpufrequtils

    ENABLE="true"
    GOVERNOR="ondemand"
    MAX_SPEED=800000
    MIN_SPEED=800000

    #GOVERNOR
    #powersave
    #conservative
    #hotplug
    #ondemand
    #smartass
    #interactive
    #performance




  • ネットワーク応用

  •  

    長期運用前提のサーバ系は動作中でもディスク交換可能な
    RAID構成を取る シンプルな方が手入れしやすい

    運用中にディスクを交換しても動作する
    定期交換の習慣を持つ 負荷がかかっても影響が出にくい

    ほったらかしのRAID5は結構恐ろしいものです。
    RAID1だと定期交換は1本で済みます。

    ディスクは自動車で言うとオイルみたいなものです。
    いい状態を長く保ちたい場合は、量が減ったり劣化したり
    壊れてしまう前に交換しましょう。

    年間維持保守にかかる手間と時間を考慮すると
    セキュリティ確保や通信制御は専用装置で行う方が
    効率がいい

    CVS/SVNサーバはイントラ内に配置出来て、最近流行のGitHubは
    地球のどこかで運用されています。遠隔地開発に有利。



  • MySQLレプリケーション

  •  

    負荷分散とスケール チューニング

    どのような場合に有効か
    ・同時接続数が足りずに表示に時間がかかる エラーが出る 
    ・アクセス数が多い時間帯に重くなる 負荷を分散したい
     データベースを更新系と表示系に分けて運用する
    ・メモリチューニング 同時接続数チューニング

    表示系はSlaveAを参照し、データのバックアップはSlaveBで行う
    負荷分散 同時接続数が足りない場合はSlaveAを増やす



  • ファイルのミラーリング 運用計画

  •  

    消えては困るファイルがある これを保護したい
    シンプルな方が手入れしやすい

    特に時間をかけて作ったファイル
    オリジナルデータ

    更新の少ないファイルサーバを連結して使う

    運用計画:バックアップ
     どこを対象とするか
     定期点検いつにするか
     駆動部品、消耗品の定期交換

    あまり大容量だと時間と負荷がかかって大変ですが
    ここに入れておけば滅多に消えないというゾーンを作り出します。



  • CVS /SVN リポジトリ バージョンコントロール

  •  

    更新履歴が取れる
    巻き戻しも出来る

    じっくり考慮して細かく修正する場合に有益
    複数名で開発する場合、チェックアウトしてから編集して
    コミットする習慣があると、ファイルの競合問題を最小限に
    抑えることが出来る

    継続的な調整が重要

    Windows系の人にはTrac+lightning(月)というキーワードもあります。

    和文の原稿作成 入校 校正プロセスも
    CVS/SVNバージョンコントロールが結構利きます。
    巻き戻せるからバッサリリメイク出来るという安心感



  • ネットワークサーバ連携

  •  

    パッケージのバージョンアップ OSのアップグレードに対応しやすい
    処理系ファイルとデータの分離を行うと手入れがしやすい 混ざっていると大変 
    画像と処理系の分離 バックアップがなかなか終わらないし重くなる等を回避

    同時接続数が足りない場合に有効

    負荷の大きな処理 バックアップ コンパイル アップデート



  • Ubuntuでnfs

  • apt-get install nfs-kernel-server

    設定
    /etc/exports
     /path/to/dir 192.168.0.0/255.255.255.0(rw,sync,no_root_squash,insecure)

    Operation not permittedとエラーが出る場合はinsecureを追加する

    再読み込み
     exportfs -r
    マウント
     sudo mount -t nfs -o rw,nfc 192.168.0.2:/home/test /mnt/nfs

    #クライアントとサーバの組み合わせによりsyncをasyncにすると速くなる場合がある



  • 世代バックアップ

  • pdumpfs /path/to/source /path/to/backup



  • サーバを分けて負荷分散

  •  

    主にブログを運営していたり、既存のサイトが重くなってきたという方向けに
    高速化の一例や対策の概念図を紹介します。#Webサイトの高速化

    難しいと感じた場合は、身の回りに得意な人が居ないか探してみることを
    お勧めします。業務で取り扱っており対価を支払えば初期設定などの煩雑な
    作業を代行してくれるところもあります。スライドを参考にこういう対策を
    施したい旨を伝えると、はかどるかもしれません。

    自分で取り組みたいと思う場合は、知識の習得から設定、検証、コツと要領を見いだすのに
    調整余力込みで約1ヶ月 その他、継続的な知識の更新などの労力が発生します。
    ※調整余力は教科書通りに行かない部分をさします。更新で仕様が変わって調査が必要など
    インターネット向けの場合はVPSの利用で若干期間を短縮できます。

    本業を抱えており、手分けして取り組みたいという人は通常発注する領域です。
    こういう環境を用意してほしいと伝えれば専門家が構築してくれます。
    本業や原稿作りに専念したいから、これのここのところ頼むよという話がよくあります。

    #ハイレスポンスサーバ構築のヒントになりそうな事柄について記述

    慣れている人は細かな点のノウハウをもっていたり主に点検分野の視点について
    コツとツボを押さえています。この時期の物はこうで、このログを見ると異常が分かるなど

    中長期的にみると、問題やアップデートが発生した場合のサポートも
    気にかけておいた方が無難です。

    都度対応で問題出たら連絡を受け修正サポートを受ける、
    ハードウエア点検、ログの肥大化チェック、エラー点検、
    セキュリティ点検を含んだ年間保守契約を結ぶなど

    ディスクはホットスワップ対応のRAID1以上を選択しましょう。
    故障の未然防止のためディスクの定期交換などが行えます。

    セキュリティ設定や初期の動作確認を考慮すると結構なボリュームになります。
    全部ではなくSQLだけ強化したい、WebサーバとDBサーバを分離したいなどの話も多く上がります。

    Webサーバはレイテンシスコアの高いところを選択して、DBサーバにはお金をかける
    (ハイスペックマシンを用意する)という手もあります。

    ハイレスポンスサイトを構築する
    アクセス数が増えてレスポンスが悪くなった場合に、高速化の鍵を握るのは以下の3点
    ・高速なディスク
    ・高性能な演算装置
    ・占有型ネットワーク

    負荷を分散させ快適にする

    webサーバとDBサーバを分離して負荷を分散させる
     #必要に応じて強化しやすくなる
     ・強力なDBサーバ マスタとスレーブを設置しスレーブを参照する
      登録、更新はマスタで行う 規模や負荷の兼ね合いでスレーブを2台用意する
      などの拡張が可能です。
     ・高速なWEBサーバ複数台でアクセスを処理する
     ・画像サーバを分離する 重いデータのトラフィック分散
     ・ネットワーク接続回線を分ける

    リバースプロキシを構築し複数台でWEBリクエストを処理する
     ngnix squidによる負荷分散

    開発開始の初期段階でWebサーバとDBサーバを切り分けておくとスケールしやすい

    #高速な回線を持つWebサーバ #強力な処理能力を持つDBサーバ の2つに分けて
    始めると後で柔軟な調整がしやすくなります。
    (別筐体を前提とすると自然とコードの切り分けしやすく、拡張しやすくなります)

    アクセス数が増えてDBサーバの応答速度(レスポンス)が落ちてきたら、
    マスタを更新してスレーブを参照するようにコードを書き換えていきます。

    Webがこけても復旧しやすい運用体制を組むなど、運用計画(定期的なバックアップ)も
    重要です。数を見ていると故障のほか、落雷による破損も多いです。
    壊れたときにどう修理するか、軽く気にかけておいた方が無難です。

    画像が多くてアクセスが急増すると応答速度が遅くなる
    という場合はリバースプロキシによるWebサーバの負荷分散を行う事が多いです。

    動画の場合はかなり通信量が大きくなるので、YouTubeにアップロードがベターです。
    どうしても自前で用意する場合は、IXに直結した構造をとらないと再生が途中で止まる
    などの現象が出てきます。

    停止せずに高速稼働という要件であれば本格的に予算をとって
    担当つけてメンテナンスを継続的に行うというパターンになります。

    この場合は高度な技術力も必要ですし安定雇用の確保や、機密保持契約などの
    関連も出てくる為非常に高額になります。この文書はそこまで求めてない
    という場合の物です。そこまで求めていないけれど、どういう方法があるのか
    知りたいという人向けです。

    データがあれば復旧できる 思い切ってリニューアルも出来る
    対して、データが消えると大変です。

    インフラ整備とデザイン、マーケティングは手分けすることも多いです。
    得意な人や取り組みたい人を捜して手分けするとうまく行きます。
    専門知識が違うので効率よく平行して進行しやすい分野です。

    単機能サーバを連携させる運用は性能を出しやすいです。大きな
    画像をロードしてスワップが発生してDBが遅くなる といった状況を回避できるなど