Hello, I found that there is also a third-party iSCSI implementation that claims to support RBD: https://github.com/fujita/tgt I use it in a non-Ceph context, and it works well. Question: Does anyone have any experience running tgt as an alternative to tcmu-runner? If so, which clients (iSCSI initiators) do you use? On Mon, Feb 10, 2025 at 11:22 PM Adam King <adking@redhat.com> wrote:

ISCSI is still being used in the LRC (long running cluster) that is a storage backend for parts of the ceph team's infrastructure, so I don't think it's going to disappear in the near future. I believe the plan is to eventually swap over to nvmeof instead ( https://docs.ceph.com/en/reef/rbd/nvmeof-overview/) but nvmeof isn't ready in squid iirc.

On Mon, Feb 10, 2025 at 6:27 AM Iban Cabrillo <cabrillo@ifca.unican.es> wrote:

...

Good morning,

I wanted to inquire about the status of the Ceph iSCSI gateway service. We currently have several machines installed with this technology that are working correctly,

although I have seen that it appears to be discontinued since 2022. My question is whether to continue down this path, adding machines, or whether it will be discontinued in new Ceph distributions.

Best regards and thanks in advance. --

================================================================ Ibán Cabrillo Bartolomé Instituto de Física de Cantabria (IFCA-CSIC) Santander, Spain Tel: +34942200969/+34669930421 Responsible for advanced computing service (RSC) =========================================================================================

=========================================================================================

All our suppliers must know and accept IFCA policy available at:

https://confluence.ifca.es/display/IC/Information+Security+Policy+for+Extern... ==========================================================================================

_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io

-- Alexander Patrakov

Okay Gregory, Bad news for me, I will have to find another way. The truth is that from the operational and long-term maintenance point of view it is practically transparent. This option fitted very well in our system, since the Ceph cluster is easy to maintain, while for example the iSCSI cabinets have to be migrated every certain time. In our case where the use of block access is not intensive, the truth is that we were not having a bad performance, it is also true that until now I had only exported 4 blocks with this system. Regards, I -- ================================================================ Ibán Cabrillo Bartolomé Instituto de Física de Cantabria (IFCA-CSIC) Santander, Spain Tel: +34942200969/+34669930421 Responsible for advanced computing service (RSC) ========================================================================================= ========================================================================================= All our suppliers must know and accept IFCA policy available at: https://confluence.ifca.es/display/IC/Information+Security+Policy+for+Extern... ==========================================================================================

You can compile this iscsi stuff not? I did this recently with a recent ceph version. But noticed it was performing less than just a rbd mount.

Okay Gregory, Bad news for me, I will have to find another way. The truth is that from the operational and long-term maintenance point of view it is practically transparent. This option fitted very well in our system, since the Ceph cluster is easy to maintain, while for example the iSCSI cabinets have to be migrated every certain time.

In our case where the use of block access is not intensive, the truth is that we were not having a bad performance, it is also true that until now I had only exported 4 blocks with this system.

Hi Alan, We use containers deployed by the orchestrator and cephadm on a bare-metal nodes, but this is not important for PetaSAN since it doesn't manage our external cluster. I synthesized my notes here [1] this week. If you follow the guide, please share your experience and feel free to open an issue if you see any points that could be improved. Best regards, Frédéric. [1] https://github.com/frednass/ceph_petasan ----- Le 17 Fév 25, à 15:28, Alan Murrell Alan@t-net.ca a écrit :

Hi Frederic,

...

We've been successfully using PetaSAN [1] iSCSI gateways with an external Ceph cluster (not the one deployed by PetaSAN itself) on VMware hypervisors (135 VMs, 75TB) for a year and a half.

I am interested in this.

We are currently using a TrueNAS VM on our Proxmox cluster that is exporting its vDisk via iSCSI, which is less than ideal, after find extremely poor performance with the iSCSI in Ceph Currently just using that iSCSI solution for a backup repository for Veeam, but we would like to use iSCSI with our Ceph cluster to move some of our VMs on VMware (that we haven't been able to migrate to the Proxmox cluster yet) to it so we can clear off one or two of our traditional SANs and connect them to our Proxmox cluster as additional storage in addition to our Ceph cluster.

Is your Ceph cluster on bare metal or deployed using cephadm? Is there a document or guide you followed to install PeteSAN with using an external Ceph cluster? All I can seem to find at the moment are for deploying PetaSAN using its own Ceph implementation. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io