In the context of Scrum, a Sprint is a timebox. It has a start and it has an end. Once a Sprint starts, it's timebox is fixed - it will end when it is scheduled to end. There is no concept of adjusting the end date of the Sprint because things come up.
Based on this and the problems that you're describing, I do have some suggestions.
First, I would decouple the notion of your release cadence from the Sprint cadence. At the end of a Sprint, you have a "potentially releasable Increment of "Done" product". However, there is no constraint that the team cannot produce a potentially releasable Increment of "Done" product at any point within the Sprint. There is also no constraint that a release is done only at the end of a Sprint. If, during the course of a Sprint, the team produces a potentially releasable Increment of "Done" product, the Product Owner may choose to release it. Whatever the most recently completed potentially releasable Increment of "Done" product is at the end of the Sprint is the input to the Sprint Review - this may be something that is already released, the Sprint Review is simply the formal event scheduled to align the stakeholders and the Scrum Team with the next steps by sharing lessons learned and feedback.
Second, I would address the problems with people being pulled off. It's well known that context switching not only slows down progress, but can reduce the quality of work. Consider some of the principles of Agile Software Development and Lean Software Development. Is this context switching consistent with giving motivated individuals the environment they need to get the job done? Is this sustainable development and can it be maintained indefinitely? Is this introducing unnecessary waste (partially done work, task switching, waiting, handoffs, extea cognitive load) that can be reduced or eliminated?
I don't have enough information about your organization and teams to say for sure if it makes sense to continue using Scrum. However, I would consider introducing some metrics from Kanban in order to get some more insight into the impact of this context switching that is happening. I'd look at cycle time for work items, from the time that they are started to the time that they are "done". I'd look at work item aging, or how long a work item spends at each stage in the process. I'd look at work in progress and how many work items are at each stage at a given moment in time. I'd also look at some kind of quality metrics - how defects are found that are associated with different work items requiring rework and try to correlate it to cases of context switching or a lot of WIP.