<div dir="ltr"><div><div><div><div>Hi Amudhan,<br><br>
<p>
Please go through the following that would clarify up-gradation concerns from DHT to RIO in 4.0
</p>
<p>
</p><ol start="1" type="1"><li>RIO would not deprecate DHT. Both DHT and RIO would co-exist.</li><li>DHT volumes would not be migrated to RIO. DHT volumes would still be using DHT code.</li><li>The new volume creation should specifically opt for RIO volume once RIO is in place.</li><li>RIO should be perceived as another volume type which is chosed during volume creation<br>just like replicate, EC which would avoid most of the confusions. <br></li></ol><p>Shaym,</p><p>Please add if I am missing anything.</p><p>Thanks,<br>Kotresh HR<br></p></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 4:36 PM, Amudhan P <span dir="ltr"><<a href="mailto:amudhan83@gmail.com" target="_blank">amudhan83@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">does RIO improves folder listing and rebalance, when compared to 3.x?<div><br><div>if yes, do you have any performance data comparing RIO and DHT?</div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 2, 2017 at 4:12 PM, Kaushal M <span dir="ltr"><<a href="mailto:kshlmster@gmail.com" target="_blank">kshlmster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, Nov 2, 2017 at 4:00 PM, Amudhan P <<a href="mailto:amudhan83@gmail.com" target="_blank">amudhan83@gmail.com</a>> wrote:<br>
> if doing an upgrade from 3.10.1 to 4.0 or 4.1, will I be able to access<br>
> volume without any challenge?<br>
><br>
> I am asking this because 4.0 comes with DHT2?<br>
<br>
</span>Very short answer, yes. Your volumes will remain the same. And you<br>
will continue to access them the same way.<br>
<br>
RIO (as DHT2 is now known as) developers in CC can provide more<br>
information on this. But in short, RIO will not be replacing DHT. It<br>
was renamed to make this clear.<br>
Gluster 4.0 will continue to ship both DHT and RIO. All 3.x volumes<br>
that exist will continue to use DHT, and continue to work as they<br>
always have.<br>
You will only be able to create new RIO volumes, and will not be able<br>
to migrate DHT to RIO.<br>
<div class="m_-4969159419411745521HOEnZb"><div class="m_-4969159419411745521h5"><br>
><br>
><br>
><br>
><br>
> On Thu, Nov 2, 2017 at 2:26 PM, Kaushal M <<a href="mailto:kshlmster@gmail.com" target="_blank">kshlmster@gmail.com</a>> wrote:<br>
>><br>
>> We're fast approaching the time for Gluster-4.0. And we would like to<br>
>> set out the expected upgrade strategy and try to polish it to be as<br>
>> user friendly as possible.<br>
>><br>
>> We're getting this out here now, because there was quite a bit of<br>
>> concern and confusion regarding the upgrades between 3.x and 4.0+.<br>
>><br>
>> ---<br>
>> ## Background<br>
>><br>
>> Gluster-4.0 will bring a newer management daemon, GlusterD-2.0 (GD2),<br>
>> which is backwards incompatible with the GlusterD (GD1) in<br>
>> GlusterFS-3.1+. As a hybrid cluster of GD1 and GD2 cannot be<br>
>> established, rolling upgrades are not possible. This meant that<br>
>> upgrades from 3.x to 4.0 would require a volume downtime and possible<br>
>> client downtime.<br>
>><br>
>> This was a cause of concern among many during the recently concluded<br>
>> Gluster Summit 2017.<br>
>><br>
>> We would like to keep pains experienced by our users to a minimum, so<br>
>> we are trying to develop an upgrade strategy that avoids downtime as<br>
>> much as possible.<br>
>><br>
>> ## (Expected) Upgrade strategy from 3.x to 4.0<br>
>><br>
>> Gluster-4.0 will ship with both GD1 and GD2.<br>
>> For fresh installations, only GD2 will be installed and available by<br>
>> default.<br>
>> For existing installations (upgrades) GD1 will be installed and run by<br>
>> default. GD2 will also be installed simultaneously, but will not run<br>
>> automatically.<br>
>><br>
>> GD1 will allow rolling upgrades, and allow properly setup Gluster<br>
>> volumes to be upgraded to 4.0 binaries, without downtime.<br>
>><br>
>> Once the full pool is upgraded, and all bricks and other daemons are<br>
>> running 4.0 binaries, migration to GD2 can happen.<br>
>><br>
>> To migrate to GD2, all GD1 processes in the cluster need to be killed,<br>
>> and GD2 started instead.<br>
>> GD2 will not automatically form a cluster. A migration script will be<br>
>> provided, which will form a new GD2 cluster from the existing GD1<br>
>> cluster information, and migrate volume information from GD1 into GD2.<br>
>><br>
>> Once migration is complete, GD2 will pick up the running brick and<br>
>> other daemon processes and continue. This will only be possible if the<br>
>> rolling upgrade with GD1 happened successfully and all the processes<br>
>> are running with 4.0 binaries.<br>
>><br>
>> During the whole migration process, the volume would still be online<br>
>> for existing clients, who can still continue to work. New clients will<br>
>> not be possible during this time.<br>
>><br>
>> After migration, existing clients will connect back to GD2 for<br>
>> updates. GD2 listens on the same port as GD1 and provides the required<br>
>> SunRPC programs.<br>
>><br>
>> Once migrated to GD2, rolling upgrades to newer GD2 and Gluster<br>
>> versions. without volume downtime, will be possible.<br>
>><br>
>> ### FAQ and additional info<br>
>><br>
>> #### Both GD1 and GD2? What?<br>
>><br>
>> While both GD1 and GD2 will be shipped, the GD1 shipped will<br>
>> essentially be the GD1 from the last 3.x series. It will not support<br>
>> any of the newer storage or management features being planned for 4.0.<br>
>> All new features will only be available from GD2.<br>
>><br>
>> #### How long will GD1 be shipped/maintained for?<br>
>><br>
>> We plan to maintain GD1 in the 4.x series for at least a couple of<br>
>> releases, at least 1 LTM release. Current plan is to maintain it till<br>
>> 4.2. Beyond 4.2, users will need to first upgrade from 3.x to 4.2, and<br>
>> then upgrade to newer releases.<br>
>><br>
>> #### Migration script<br>
>><br>
>> The GD1 to GD2 migration script and the required features in GD2 are<br>
>> being planned only for 4.1. This would technically mean most users<br>
>> will only be able to migrate from 3.x to 4.1. But users can still<br>
>> migrate from 3.x to 4.0 with GD1 and get many bug fixes and<br>
>> improvements. They would only be missing any new features. Users who<br>
>> live on the edge, should be able to the migration manually in 4.0.<br>
>><br>
>> ---<br>
>><br>
>> Please note that the document above gives the expected upgrade<br>
>> strategy, and is not final, nor complete. More details will be added<br>
>> and steps will be expanded upon, as we move forward.<br>
>><br>
>> To move forward, we need your participation. Please reply to this<br>
>> thread with any comments you have. We will try to answer and solve any<br>
>> questions or concerns. If there a good new ideas/suggestions, they<br>
>> will be integrated. If you just like it as is, let us know any way.<br>
>><br>
>> Thanks.<br>
>><br>
>> Kaushal and Gluster Developers.<br>
>> ______________________________<wbr>_________________<br>
>> Gluster-users mailing list<br>
>> <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
>> <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks and Regards,<br></div>Kotresh H R<br></div></div>
</div>