<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Iptima &#187; registar</title>
	<atom:link href="http://www.iptima.com/tag/registar/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.iptima.com</link>
	<description>... Miscellanées multimedia ®</description>
	<lastBuildDate>Tue, 08 Jun 2010 10:42:20 +0000</lastBuildDate>
	
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Changer d&#8217;hébergeur Web sans interruption de service</title>
		<link>http://www.iptima.com/2008/08/22/changer-dhebergeur-web-sans-interruption-de-service/</link>
		<comments>http://www.iptima.com/2008/08/22/changer-dhebergeur-web-sans-interruption-de-service/#comments</comments>
		<pubDate>Fri, 22 Aug 2008 09:09:32 +0000</pubDate>
		<dc:creator>Vincent Roulet</dc:creator>
				<category><![CDATA[Conception]]></category>
		<category><![CDATA[Notes de lecture]]></category>
		<category><![CDATA[Dns]]></category>
		<category><![CDATA[Domain Name System]]></category>
		<category><![CDATA[hébergeur]]></category>
		<category><![CDATA[Internet Protocol]]></category>
		<category><![CDATA[Ip]]></category>
		<category><![CDATA[MySql]]></category>
		<category><![CDATA[registar]]></category>
		<category><![CDATA[Sql]]></category>
		<category><![CDATA[Standard Query Language]]></category>
		<category><![CDATA[Tld]]></category>
		<category><![CDATA[Top Level Domains]]></category>
		<category><![CDATA[Traceroute]]></category>

		<guid isPermaLink="false">http://www.iptima.com/?p=179</guid>
		<description><![CDATA[Mécontent de notre hébergeur (dénis de service parfois prolongés sur nos sites et autres dysfonctionnements dûs à un serveur mutualisé à saturation&#8230;), nous avons songé à transférer nos données vers un nouveau prestataire. Or, nous redoutions la coupure temporaire de nos sites (peut-être avions-nous mal cerné situer le problème&#160;!)&#160;: le changement d&#8217;hébergeur contraint à changer [...]]]></description>
			<content:encoded><![CDATA[<p>Mécontent de notre hébergeur (dénis de service parfois prolongés sur nos sites et autres dysfonctionnements dûs à un serveur mutualisé à saturation&#8230;), nous avons songé à transférer nos données vers un nouveau prestataire. Or, nous redoutions la coupure temporaire de nos sites (peut-être avions-nous mal cerné situer le problème&#160;!)&#160;: le changement d&#8217;hébergeur contraint à changer les adresses <acronym title="Domain Name System">Dns</acronym>, qui mettent en entre 24 et 48 heures en théorie (ce délai de prudence est peut-être motivé par des raisons juridiques&#8230;) pour se propager pour que les serveurs de noms locaux prennent en compte la modification.</p>
<p><span id="more-179"></span></p>
<p>Pour contourner l&#8217;interruption de service en cas de changement d&#8217;hébergeur, quelques scripts sont disponibles, mais nous n&#8217;avions nullement envie d&#8217;investir du temps en <em>bidouillage</em>. Une solution pérenne et fiable nous semblait préférable.</p>
<p>Aussi avons-nous tenu le raisonnement suivant&#8230; Si nous copions nos données vers un hébergeur B en les laissant intact sur l&#8217;hébergeur A, nos sites ne devraient pas connaître d&#8217;interruption de service. Les serveurs de noms locaux qui auront pris en compte la modification vers B dirigeront les visiteurs vers B&#160;; les serveurs de noms locaux qui n&#8217;auront pas pris en compte la modification vers B dirigeront les visiteurs vers A.</p>
<p>Se pose, certes, la question du transfert par <acronym title="File Transfert Protocol">Ftp</acronym> du contenu vers le nouvel hébergeur, tant que l&#8217;adresse n&#8217;est pas résolue&#160;: au lieu d&#8217;utiliser l&#8217;adresse <em>ftp.monsite.com</em>, il suffit d&#8217;indiquer à titre temporaire l&#8217;adresse <acronym title="Internet Protocol">Ip</acronym> indiquée par l&#8217;hébergeur.</p>
<p>Pour l&#8217;anecdote, nous avons changé d&#8217;hébergeur trois sites, durant la journée du 21 août 2008, entre 15 h 00 et 20 h 00. (Pour les amateurs de géographie, l&#8217;ancien serveur était situé à Karlsruhe, en Allemagne, le nouveau à Las Vegas, aux États-Unis d&#8217;Amérique.) Deux possédaient la <acronym title="Top Level Domains">Tld</acronym> <em>.info</em>, l&#8217;autre la <acronym title="Top Level Domains">Tld</acronym> <em>.com</em>. (La précision est donnée, car il semble que la vitesse de propagation des <acronym title="Domain Name System">Dns</acronym> soit différente selon l&#8217;extension.) Nous avons utilisé l&#8217;outil réseau <em>Traceroute</em> pour mesurer le temps pris par le changement d&#8217;hébergeur après déclaration des nouvelles directions <acronym title="Domain Name System">Dns</acronym> auprès de notre <em>Registar</em>&#160;:</p>
<ul>
<li>notre premier site en <em>.info</em> a demandé trois heures pour être correctement redirigé,</li>
<li>notre deuxième site en <em>.com</em> a demandé deux heures pour être correctement redirigé,</li>
<li>notre troisième site en <em>.info</em> a demandé deux heures pour être correctement redirigé.</li>
</ul>
<p>(<em>Nota</em>. Ces mesures n&#8217;ont assurément aucune valeur, hormis informative&#160;!)</p>
<p>Nous sommes loin des 24 à 48 heures prévues&#160;; cette hypothèse nous conforte dans l&#8217;idée que nous avions mal appréhendé la question.</p>
<p>Sur le plan chronologique, nous avons effectué la migration dans l&#8217;ordre suivant&#160;:</p>
<ul>
<li>copie de nos répertoires et de nos pages par <acronym title="File Transfert Protocol">Ftp</acronym>;</li>
<li>copie de nos bases de données <acronym title="Standard Query Language">Sql</acronym> <em>via</em> <em>phpMyAdmin</em>&#160;;</li>
<li>déclaration des nouvelles directions <acronym title="Domain Name System">Dns</acronym> auprès de notre <em>Registar</em>.</li>
</ul>
<p>(Sous <em>WordPress</em>, aucune réinstallation n&#8217;a été nécessaire.)</p>
<p>Nous avons choisi de ne pas modifier le contenu de nos sites pendant quelques heures pour simplifier la gestion de la procédure (le problème serait fort différent pour un vendeur en ligne&#160;!). Aucune donnée n&#8217;a été perdue, hormis quelques <em>logs</em> de connexion des visiteurs récupérés <em>manuellement</em> chez l&#8217;ancien hébergeur.</p>
<p>L&#8217;unique contrainte de l&#8217;opération consiste à disposer des services de son ancien hébergeur, pendant quelques jours.</p>
<p>En vérifiant le positionnement de l&#8217;article dans les moteurs de recherche, nous venons de nous apercevoir que Francis avait commis un <a href="http://www.fran6art.com/wordpress/wordpress-reussir-son-changement-dhebergement-en-7-etapes/" onclick="window.open(this.href); return false;" title="lire l'article réussir son changement d'hébergeur en sept étapes  (s'ouvre dans une nouvelle fenêtre)">article</a> similaire, concernant <em>WordPress</em>&#160;!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.iptima.com/2008/08/22/changer-dhebergeur-web-sans-interruption-de-service/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
