How can I deal with recurring meetings (like trainnings or feedbacks) in Scrum? Are they impediments? Do I have to plan less User Stories during the sprint planning? How can I deal with this situations?
If "recurring" means they occur each and every sprint and occupy the same amount of time: just don't plan for them. Your velocity will adjust to the amount of work you get done in the sprint's "free" time. This will be less with more recurring things, but velocity will reflect the work you get done.
If the "recurring" things occur irregular or take different amounts of time. Plan for them just like you would for every other work item. Otherwise your velocity keeps jumping up and down, even if your estimations are perfect.
Of course this somewhat depends on your office culture, but I've found that ensuring that the inter-sprint time is used for these activities. When I say "inter-sprint" I mean that day or so of other activities that make for productive sprints. In specific, between sprints, my teams hold a sprint retrospective (the place for feedback and discussions of improvement) and sprint planning activities (planning poker, communications with the Product Owners, etc.). These "rituals" should be included in your regular sprint schedule, so you should not have to reduce the number of story points covered each sprint. On the other hand, if you know that there will be a resource hit due to training or vacation time, then you should impose an efficiency loss for the sprint and reduce the number of story points of the sprint (velocity) by the percent loss in efficiency. Your development team still needs to buy into the commitment for the sprint, but by having the timed rituals clearly established and ensuring that team members know that they are not expected to operate at full capacity if they are not available, then this should smooth out timing issues. For problems that come up that will require additional research to establish an understanding of scope and complexity you may need to schedule research spikes into the following sprint. This can reduce the amount of product produced, but also makes account of the developers' times when handling difficult problems.