12月6日の開拓者はヒョードル・チスチャコフとF4BAND （ ゼロの元リード歌手）でした。 ライブ放送中に、純粋なスタジオサウンドとライブコンサートの雰囲気を鑑賞することができた約300人がいました。
この放送のために、 Clodoは容量と500メガビット/秒の幅のチャンネルを割り当てました。 128キロビット/秒のストリームのかなり高品質のビットレートの場合、これは4,000クライアントが「真空状態」にあることを意味しました。 最大2,000人のリスナーが来て安全になると想定していましたが、今回はパートナーと合意に達することができず、視聴者の見積もりは大きく過小評価されていました。 Habréから関心のある人々を連れて行こうとする試みは、Dudlik habratovarischaの禁止に終わりました。
それにもかかわらず、私たちはコンサートを開くことに非常に成功しました。 技術的な実装について簡単に説明します-汎用bashスクリプトを使用した負荷分散で、Icecast2プログラムを複数のサーバーで使用しました。 カットの下の詳細。
技術的な実装
ホスティング機能を利用するには、5つのインスタンスを作成する必要があり、各インスタンスには100メガビット/秒が割り当てられていました。 システムの相互作用の一般的なスキームは次のようになりました。
ソースストリームがブロードキャストされた最初のサーバー（プレゼンターとミュージシャン）があり、彼はすでに次のことに従事していました。
1）顧客向けの実際の放送ストリーム。
2）他のサーバーへの中継。
オーディオストリームを配信するために、Ubuntu 10.04リポジトリのIcecast2を使用しました。 要するに、翻訳サーバーにインストールする必要があったパッケージのリストです。
g++ libmp3lame-dev libshout3-dev icecast2 libperl-dev libmp3-info-perl
ソースストリームが存在しない場合、最初のサーバーは特定のディレクトリから音楽をブロードキャストします。 ソースから収集したIces 0.4を使用して、ノンストップストリームが形成されます。
音楽は/ home / ftpディレクトリに保存され、 ここから取得したPerlモジュールを使用してID3タグが引き出されました （このために--with-perlスイッチで氷を収集しました）。 構成/usr/local/etc/ices.conf：wget http://downloads.us.xiph.org/releases/ices/ices-0.4.tar.gz tar -zxvf ices-0.4.tar.gz cd ices-0.4 ./configure --with-perl 作る インストールする
<？xml version = "1.0"？>
<ices：構成xmlns：ices = "http://www.icecast.org/projects/ices">
<プレイリスト>
<ランダム化> 1 </ランダム化>
<Type> perl </ Type>
<モジュール>アイス</モジュール>
<クロスフェード> 5 </クロスフェード>
</プレイリスト>
<実行>
<背景> 0 </背景>
<詳細> 0 </詳細>
<BaseDirectory> / tmp </ BaseDirectory>
</実行>
<ストリーム>
<サーバー>
<ホスト名> air1.appleinsider.ru </ホスト名>
<ポート> 1976 </ポート>
<Password> SOURCEPASSWORD </ Password>
<Protocol> http </ Protocol>
</ Server>
<マウントポイント> /ノンストップ</マウントポイント>
<Name> AppleInsider.ru Radio </ Name>
<Genre>が指定されていません</ Genre>
<説明>リスナーからの音楽</説明>
<URL> http://www.appleinsider.ru/ipodcast/ </ URL>
<パブリック> 1 </パブリック>
<ビットレート> 128 </ビットレート>
<Reencode> 1 </ Reencode>
<Samplerate> 44100 </ Samplerate>
<チャネル> 2 </チャネル>
</ストリーム>
</ ices：設定>
以下は、最初のサーバー構成（パス、ロギング、セキュリティセクションを省略）、/ etc / icecast2 / icecast.xmlファイルの最も興味深い場所です。
<アイスキャスト>
<制限>
<clients> 1000 </ clients>
<sources> 6 </ sources>
<queue-size> 524288 </ queue-size>
<client-timeout> 30 </ client-timeout>
<header-timeout> 15 </ header-timeout>
<source-timeout> 10 </ source-timeout>
<burst-on-connect> 1 </ burst-on-connect>
<burst-size> 65535 </ burst-size>
</ limits>
<認証>
<source-password> SOURCEPASSWORD </ source-password>
<relay-password> RELAYPASSWORD </ relay-password>
<admin-user> admin </ admin-user>
<admin-password> ADMINPASSWORD </ admin-password>
</認証>
<hostname> air1.appleinsider.ru </ hostname>
<listen-socket>
<port> 1976 </ port>
</ listen-socket>
<マウント>
<マウント名> /ノンストップ</マウント名>
<charset> UTF8 </ charset>
</ mount>
<マウント>
<mount-name> / air </ mount-name>
<max-listeners> 600 </ max-listeners>
<charset> UTF8 </ charset>
<fallback-mount> /ノンストップ</ fallback-mount>
<fallback-override> 1 </ fallback-override>
</ mount>
。 。 。
</ icecast>
2番目以降のサーバーの構成では、リレーセクションとマウントセクションに特に注意を払います。
<アイスキャスト>
<制限>
<clients> 1000 </ clients>
<sources> 6 </ sources>
<queue-size> 524288 </ queue-size>
<client-timeout> 30 </ client-timeout>
<header-timeout> 15 </ header-timeout>
<source-timeout> 10 </ source-timeout>
<burst-on-connect> 1 </ burst-on-connect>
<burst-size> 65535 </ burst-size>
</ limits>
<認証>
<relay-password> RELAYPASSWORD </ relay-password>
<admin-user> admin </ admin-user>
<admin-password> ADMINPASSWORD </ admin-password>
</認証>
<hostname> air2.appleinsider.ru </ hostname>
<listen-socket>
<port> 1976 </ port>
</ listen-socket>
<リレー>
<server> air1.appleinsider.ru </ server>
<port> 1976 </ port>
<mount> / air </ mount>
<ローカルマウント> /エア</ローカルマウント>
<username>リレー</ username>
<password>リレーパスワード</ password>
<オンデマンド> 0 </オンデマンド>
</ relay>
<マウント>
<mount-name> / air </ mount-name>
<max-listeners> 600 </ max-listeners>
<charset> UTF8 </ charset>
</ mount>
。 。 。
</ icecast>
したがって、2番目と次のサーバーでicecast2が起動すると、最初のサーバーの/ airマウントポイントに自動的に接続し、「オンザフライ」でコピーして、同じ名前のマウントポイントでの配布/マウントを開始します。 サーバーごとに、リスナーを600個に制限しました。 理想的な場合、各サーバーのチャネルは75％で使用されます。
負荷分散
次に、負荷をどのように均等に分散するかについて説明します（結局のところ、これは必須ではありませんでした）。
リスナーは、2つの方法でオンラインコンサートにアクセスできます。Webプレーヤーを介してpodcast.appleinsider.ruページを開いて[再生]ボタンをクリックするか、 air.appleinsider.ru / apple.m3uなどのリンクを同じページにコピーして「フィード」彼女の最愛のデスクトップ/モバイルプレーヤーに。
最初のケースでは、バランシングは偶然に実行されました-クライアントがWebプレーヤーでページを開いたとき（ちなみに、 私たちによってjPlayerで構築されます ）、Javascriptを使用して1から5までの乱数が生成され、対応するサーバー（air1-air5）からストリームが取得されました。
2番目の場合、つまり ユーザーがプレーヤーにM3Uリンクを与えると、次のことが起こりました。 一般に、icecast2がserver / mount.m3uの形式のリンクを要求されると、まずファイル/usr/share/icecast2/web/mount.m3uを探し、見つかった場合はそれを渡します。 残されたのは、このファイルを正しく作成することだけでした。
1分に1回、クラウン上の各サーバーの負荷を要求し、要約統計を更新し、シンボリックリンクapple.m3uを、たとえば、このファイルに含まれる最初のサーバー用に、以前に準備したファイルの1つにリダイレクトしました。
http://air1.appleinsider.ru:1976/air
bashスクリプト自体は次のとおりです。
＃！/ bin / sh
合計= 0
IMIN = 1
最小= 100
＃各サーバーの負荷（つまり、リスナーの数）を収集します
＃これを行うには、サービスページに問い合わせて解析します
`seq 1 5`のNUM; する
DATA = `curl --silent http：//air$NUM.appleinsider.ru：1976 / status2.xsl`
AIR = `echo $ DATA | sed 's /.*\/ air //' | cut -d "、" -f4`
NONSTOP = `echo $ DATA | sed 's /.*\/ nonstop //' | cut -d "、" -f4`
if ["x $ {AIR}" = "xCurrent Listeners"]; それから
AIR = 0
fi
if ["x $ {NONSTOP}" = "xCurrent Listeners"]; それから
ノンストップ= 0
echo "air $ NUM：$ AIR"
他に
if ["x $ {NONSTOP}" = "x0"]; それから
echo "air $ NUM：$ AIR"
他に
echo "air $ NUM：$ AIR / $ NONSTOP"
fi
fi
＃NOW-NUMのサーバー負荷
NOW = `expr $ AIR + $ NONSTOP`
＃TOTAL-総負荷
TOTAL = `expr $ TOTAL + $ NOW`
＃最も負荷の少ないサーバーの数を決定する
if [$ NOW -lt $ MIN]; それから
MIN = $ NOW
IMIN = NUM
fi
やった
echo "-------------------"
echo "合計：$ TOTAL"
＃ウェブキャストページの統計を更新する
echo $ TOTAL> stat.txt
scp stat.txtポッドキャスト：/ var / www
＃M3Uファイルを更新
echo air.m3u-\> http：//air$IMIN.appleinsider.ru：1976 / air
ssh air1 ln -sf /usr/share/icecast2/web/air.m3u_$IMIN /usr/share/icecast2/web/air.m3u
echo "サーバー$ IMINは勤務中です。"
私は同意します、彼は少しxですが、労働者です。 改善の提案があれば、喜んで聞きます。
まとめ
以下は、オンラインブロードキャスト中の視聴者数のグラフです。ピーク時は280人です。
ポッドキャストを購読して、オンラインコンサートの記録をダウンロードできます： RSS | MP3 | iTunes
次のイベントは12月25日に予定されています。 参加者についてはまだ話しません。 交渉は最も活発な段階にあります。 すべての詳細と発表はAppleinsider.ruで見つけることができます