<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Uniserver vs. Servicii Distribuite</title>
	<atom:link href="http://blog.webfactor.ro/2009/08/uniserver-vs-servicii-distribuite/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.webfactor.ro/2009/08/uniserver-vs-servicii-distribuite/</link>
	<description></description>
	<lastBuildDate>Sat, 12 Nov 2011 08:45:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<meta name="generator" content="Obscure 2.0" />
	<item>
		<title>By: bogdanf</title>
		<link>http://blog.webfactor.ro/2009/08/uniserver-vs-servicii-distribuite/comment-page-1/#comment-38</link>
		<dc:creator>bogdanf</dc:creator>
		<pubDate>Fri, 21 Aug 2009 20:32:57 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webfactor.ro/?p=78#comment-38</guid>
		<description>Daca rulezi pe fiecare server un singur serviciu, atunci ai avantajul ca poti sa iti optimizezi tot serverul ca sa ruleze serviciul respectiv cat mai bine. De exemplu, in cazul unui server de MySQL, poti sa incepi de la configuratia hardware (cel mai probabil niste disk-uri mai rapide, un controller de RAID mai bunicel), la file system si sa mergi pana la optimizari in sistemul de operare, la network sau chiar kernel.&lt;br&gt;&lt;br&gt;Daca chiar vrei sa reduci riscul intreruperilor de servicii, singura solutie e sa implementezi o solutie de high availability si aia nu o faci decat intr-un mediu distribuit.&lt;br&gt;&lt;br&gt;Alt avantaj pe care il ai folosind o infrastructura cu sisteme distribuite intr-un mediu eterogen (in care ruleaza si Windows si Linux de exemplu) e ca vei putea profita din plin de avantajele fiecarui sistem de operare si de aplicatiile care ruleaza pe ele. De exemplu, probabil vei rula pe Windows doar IIS pentru clientii care doresc ASP/ASP .NET (eventual si PHP si Perl in caz ca au nevoie de ele pe aceleasi site-uri), un serviciu de FTP si eventual pe alta masina ceva server de MSSQL, pe cand MySQL-ul si serverul de mail o sa ruleze pe ceva masini cu Linux (atat din motive de performanta cat si pentru facititatile pe care le ofera in plus aplicatiile care ruleaza pe acest sistem de operare, mai ales in cazul serviciilor de mail dar si din motive de licentiere).&lt;br&gt;&lt;br&gt;In momentul de fata cam toti hosterii mai maricei distribuie servicii pentru ca cam toti au cel putin serviciul de DNS pe cel putin 2 masini, de obicei in sistem master/slave.</description>
		<content:encoded><![CDATA[<p>Daca rulezi pe fiecare server un singur serviciu, atunci ai avantajul ca poti sa iti optimizezi tot serverul ca sa ruleze serviciul respectiv cat mai bine. De exemplu, in cazul unui server de MySQL, poti sa incepi de la configuratia hardware (cel mai probabil niste disk-uri mai rapide, un controller de RAID mai bunicel), la file system si sa mergi pana la optimizari in sistemul de operare, la network sau chiar kernel.</p>
<p>Daca chiar vrei sa reduci riscul intreruperilor de servicii, singura solutie e sa implementezi o solutie de high availability si aia nu o faci decat intr-un mediu distribuit.</p>
<p>Alt avantaj pe care il ai folosind o infrastructura cu sisteme distribuite intr-un mediu eterogen (in care ruleaza si Windows si Linux de exemplu) e ca vei putea profita din plin de avantajele fiecarui sistem de operare si de aplicatiile care ruleaza pe ele. De exemplu, probabil vei rula pe Windows doar IIS pentru clientii care doresc ASP/ASP .NET (eventual si PHP si Perl in caz ca au nevoie de ele pe aceleasi site-uri), un serviciu de FTP si eventual pe alta masina ceva server de MSSQL, pe cand MySQL-ul si serverul de mail o sa ruleze pe ceva masini cu Linux (atat din motive de performanta cat si pentru facititatile pe care le ofera in plus aplicatiile care ruleaza pe acest sistem de operare, mai ales in cazul serviciilor de mail dar si din motive de licentiere).</p>
<p>In momentul de fata cam toti hosterii mai maricei distribuie servicii pentru ca cam toti au cel putin serviciul de DNS pe cel putin 2 masini, de obicei in sistem master/slave.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: [roo@Batman]#</title>
		<link>http://blog.webfactor.ro/2009/08/uniserver-vs-servicii-distribuite/comment-page-1/#comment-37</link>
		<dc:creator>[roo@Batman]#</dc:creator>
		<pubDate>Fri, 21 Aug 2009 18:46:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webfactor.ro/?p=78#comment-37</guid>
		<description>@dt riscul sa pice un server centralizat , avand in vedere ca ruleaza de obicei un singur serviciu este mic. normal aici trebuie sa ai asigurat de bun simt un raid , un ups, respectiv generator si clima adecvata. avantajul totusi daca pica un server de mysql este ca va functiona totusi contentul static. analogia este sa it mearga internetul cu pierderi/in reprize fata de cazul in care nu ar merge deloc. cred ca este mult preferat sa iti functioneze un serviciu defectuos decat deloc. nu toate aplicatiile depind de baza de date si multe din ele se pot configura sa foloseasca un sistem de cache ceea ce reduce si consumul de resurse catre serverul de mysql.&lt;br&gt;@Florin da, chiar si noi folosim unele din servicii instalate pe masini virtuale insa nu trebuie confundate masinile virtuale care le achizionati de la &quot;o firma obisnuita&quot; de hosting unde resursele dunt limitate de multe ori si de catre abonamentul contractat la valori relativ mici pentru servicii &quot;enterprise&quot;. nodul de vps-uri trebuie de asemenea sa indeplineasca conditiile de bun simt de mai sus. avantajul in a folosi serviciile pe servere virtuale este ca permit live modificarea resurselor (memorie/spatiu pe disc) si chiar migrarea pe alte servere de masini virtuale aproape fara downtime in cazul in care resursele globale nu mai sunt suficiente pe serverul actual. idem pe serverul virtual nu depinzi de diverse drivere de sata de ex care s-ar putea sa nu functioneze in cazul in care muti hdd-urile dintr-un server &quot;crepat&quot; in unul nou. teoretic si kernelul sistemelor virtuale este mai optimizat decat cel al serverelor &quot;nevirtuale&quot;.</description>
		<content:encoded><![CDATA[<p>@dt riscul sa pice un server centralizat , avand in vedere ca ruleaza de obicei un singur serviciu este mic. normal aici trebuie sa ai asigurat de bun simt un raid , un ups, respectiv generator si clima adecvata. avantajul totusi daca pica un server de mysql este ca va functiona totusi contentul static. analogia este sa it mearga internetul cu pierderi/in reprize fata de cazul in care nu ar merge deloc. cred ca este mult preferat sa iti functioneze un serviciu defectuos decat deloc. nu toate aplicatiile depind de baza de date si multe din ele se pot configura sa foloseasca un sistem de cache ceea ce reduce si consumul de resurse catre serverul de mysql.<br />@Florin da, chiar si noi folosim unele din servicii instalate pe masini virtuale insa nu trebuie confundate masinile virtuale care le achizionati de la &#8220;o firma obisnuita&#8221; de hosting unde resursele dunt limitate de multe ori si de catre abonamentul contractat la valori relativ mici pentru servicii &#8220;enterprise&#8221;. nodul de vps-uri trebuie de asemenea sa indeplineasca conditiile de bun simt de mai sus. avantajul in a folosi serviciile pe servere virtuale este ca permit live modificarea resurselor (memorie/spatiu pe disc) si chiar migrarea pe alte servere de masini virtuale aproape fara downtime in cazul in care resursele globale nu mai sunt suficiente pe serverul actual. idem pe serverul virtual nu depinzi de diverse drivere de sata de ex care s-ar putea sa nu functioneze in cazul in care muti hdd-urile dintr-un server &#8220;crepat&#8221; in unul nou. teoretic si kernelul sistemelor virtuale este mai optimizat decat cel al serverelor &#8220;nevirtuale&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Florin Matincă</title>
		<link>http://blog.webfactor.ro/2009/08/uniserver-vs-servicii-distribuite/comment-page-1/#comment-34</link>
		<dc:creator>Florin Matincă</dc:creator>
		<pubDate>Fri, 21 Aug 2009 03:11:10 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webfactor.ro/?p=78#comment-34</guid>
		<description>A încercat cineva să distribuie serviciile folosind maşini virtuale ?</description>
		<content:encoded><![CDATA[<p>A încercat cineva să distribuie serviciile folosind maşini virtuale ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dt</title>
		<link>http://blog.webfactor.ro/2009/08/uniserver-vs-servicii-distribuite/comment-page-1/#comment-33</link>
		<dc:creator>dt</dc:creator>
		<pubDate>Thu, 20 Aug 2009 23:22:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.webfactor.ro/?p=78#comment-33</guid>
		<description>Daca imi este ingaduit, pot sa mai spun eu un dezavantaj pentru &quot;Sistemele Distribuite&quot; :P Daca distribuirea se face la nivel de server fizic, atunci cel mai probabil numarul de conturi gestionat de un server/serviciu este mult mai mare decat in cazul uniserver. Iar daca acel server &quot;pica&quot;, numarul clientilor afectati este evident, mult mai mare. Acum depinde de serviciu - mysql de exemplu, daca nu functioneaza, o sa genereze erori in paginile web chiar daca serverul web, aflat pe alt server fizic, functioneaza foarte bine.</description>
		<content:encoded><![CDATA[<p>Daca imi este ingaduit, pot sa mai spun eu un dezavantaj pentru &#8220;Sistemele Distribuite&#8221; <img src='http://blog.webfactor.ro/wp-includes/images/smilies/icon_razz.gif' alt=':P' class='wp-smiley' />  Daca distribuirea se face la nivel de server fizic, atunci cel mai probabil numarul de conturi gestionat de un server/serviciu este mult mai mare decat in cazul uniserver. Iar daca acel server &#8220;pica&#8221;, numarul clientilor afectati este evident, mult mai mare. Acum depinde de serviciu &#8211; mysql de exemplu, daca nu functioneaza, o sa genereze erori in paginile web chiar daca serverul web, aflat pe alt server fizic, functioneaza foarte bine.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

